Soulbound Token (SBT) Nesting

A user's primary SBT can nest tokens representing verifiable credentials from various sources, creating a composite reputation score.

• A DeFi credit score SBT could nest sub-tokens for on-chain payment history, KYC verification, and protocol-specific governance participation.
• Lending protocols can programmatically assess the nested structure to determine creditworthiness and loan terms without exposing raw personal data.

Nesting models hierarchical membership within decentralized autonomous organizations (DAOs).

• A core DAO member SBT can nest role-specific sub-tokens (e.g., Contributor, Steward, Treasurer).
• Each nested token grants specific on-chain permissions, such as voting weight in certain sub-committees or access to multisig wallets. Revoking a role simply burns the nested sub-token, leaving the core membership intact.

Educational institutions or certification bodies can issue SBTs for degrees, which then nest tokens for individual courses or skills.

• A Computer Science Degree SBT could nest sub-tokens for Cryptography 101, Smart Contract Security, and Distributed Systems.
• This creates a portable, verifiable, and granular skill graph that employers or other educational platforms can query to understand a user's proven competencies.

A player's primary avatar or identity SBT can nest achievements, equipped items, and faction affiliations.

• Key mechanics enabled:
  • Composability: A legendary sword (as a nested SBT) can be equipped to the avatar SBT, proving ownership and status.
  • Provenance: The nested history of an item's previous owners is immutably recorded.
  • Interoperability: Games can read specific nested tokens to grant in-game benefits or access.

A product's master SBT can nest tokens from each step in its supply chain, creating an immutable lineage.

• A Coffee Bag SBT could nest tokens from the farm (origin), fair-trade certifier, roaster, and shipper.
• Consumers scan a QR code to view the entire nested provenance tree, verifying ethical sourcing and authenticity directly on-chain.

Nesting can represent complex legal ownership and regulatory compliance on-chain.

• A Legal Entity SBT for a DAO-Limited Liability Company (LLC) wrapper could nest sub-tokens representing its articles of organization, registered agent verification, and proof of tax status.
• Regulators or partners can be granted permission to view specific nested tokens, enabling transparent compliance without exposing the entity's full internal structure.

SBT nesting is the process where one SBT, acting as a parent token, holds or references one or more other SBTs as its children. This creates a non-transferable token graph where attributes, permissions, or reputation are inherited or composed. The parent SBT's metadata or smart contract logic defines the rules for which child SBTs it can hold and their significance.

A primary use case is aggregating verifiable credentials into a composite identity. For example:

• A Professional Guild SBT could nest SBTs representing individual skill certifications, course completions, and employment verifications.
• A DAO Membership SBT might nest sub-tokens proving participation in specific working groups, completed bounties, or voting history, creating a detailed, portable reputation profile.

Nesting enables sophisticated, tiered access systems. A parent SBT can grant permissions based on the nested child tokens it possesses. For instance:

• Access to a pro-tier DeFi protocol could require an SBT that nests a specific governance token stake and a KYC verification SBT.
• Entry to a private virtual venue might be gated by an SBT that nests tokens proving attendance at prerequisite events, creating a verifiable journey.

This allows a single wallet (soul) to manage multiple contextual identities under one umbrella. A user could have a "Main Identity SBT" that nests separate SBTs for their developer, artist, and governance participant roles. Each nested role-SBT can be used independently in specific ecosystems while remaining part of a verifiable, overarching identity structure, preventing identity fragmentation.

While no single universal standard exists, implementations often use:

• ERC-721 or ERC-1155 with custom logic for ownership and binding.
• Registry Contracts that maintain a mapping of parent-to-child token relationships.
• SBT-specific proposals like ERC-4973 (Account-bound Tokens) or ERC-5114 (Soulbound Badge) which provide foundational properties that can be extended for nesting logic.

Key design challenges include:

• Revocation Logic: Defining how nested child SBTs (e.g., a revoked credential) affect the parent's status.
• Graph Complexity: Managing and querying deeply nested token relationships can be computationally intensive.
• Privacy: Hierarchical structures may expose more relationship data than intended; zero-knowledge proofs are being explored to verify nested properties without revealing all details.

Nesting creates a permission hierarchy where a parent SBT's logic can govern access to its nested children. Designers must decide if revocation (burning) a parent token should:

• Cascade destroy all nested tokens.
• Orphan nested tokens, leaving them in a frozen or degraded state.
• Transfer nested tokens to a fallback address.

Incorrect logic can lead to unintended permanent loss or unauthorized persistence of nested assets.

Deeply nested SBT structures can lead to state explosion and high gas costs for operations that traverse the entire tree. Key considerations include:

• Traversal Overhead: Verifying lineage or computing aggregate reputation may require multiple on-chain reads.
• Update Propagation: Changing a root SBT's metadata may need to propagate changes down the chain, multiplying transaction costs.
• Design for Shallow Trees: Most practical implementations limit nesting depth to 2-3 levels to manage cost and complexity.

Nested SBTs must be designed to interact safely with external protocols (DeFi, DAOs, marketplaces). Risks include:

• Re-entrancy in Parent Contracts: Logic that handles nested tokens during mint/burn must be secure against re-entrancy attacks.
• Interface Standards: Lack of universal standards for nested SBTs (beyond ERC-721/1155) can cause integration failures.
• Oracle Reliance: Systems that read nested SBT data for off-chain logic (e.g., credit scoring) depend on oracle security and correct state interpretation.

The nested relationship graph is fully public on-chain, creating privacy trade-offs:

• Identity Linkage: Nested structures can explicitly map relationships between wallets, DAOs, and credentials, potentially deanonymizing users.
• Social Graph Exploitation: Malicious actors can analyze the public graph to target high-value accounts or exploit relationship-based trust models.
• Selective Disclosure Solutions: Techniques like zero-knowledge proofs (ZKPs) or private state channels may be needed to prove relationships without revealing the entire graph.

Nesting is often proposed for digital inheritance, but introduces critical recovery challenges:

• Key Loss Mitigation: A nested SBT representing a will must have a secure, time-delayed mechanism to transfer assets if the parent 'soul' is inactive.
• Social Recovery Conflicts: If a parent SBT uses social recovery, guardians must be authorized to act on nested assets, requiring clear, attack-resistant governance.
• Irreversible Mistakes: Errors in inheritance logic are potentially uncorrectable, permanently locking or misdirecting nested value.

Nesting can be exploited to create false reputation or authority through Sybil attacks. Mitigation strategies include:

• Costly Nesting: Requiring a stake or proof-of-work to create a nested link.
• Graph Validation: Implementing algorithms that discount reputation from newly created or low-stake sub-graphs.
• Attestation Weighting: Designing systems where nested attestations from highly reputable parent souls carry more weight than those from unknown sources.

A Decentralized Identifier (DID) is a globally unique, persistent identifier controlled by the subject (e.g., a user, organization, or device) without reliance on a central registry. DIDs, often implemented as wallet addresses, serve as the root "Soul" to which SBTs are bound. Nesting SBTs creates a verifiable data structure anchored to a DID, enabling portable, self-sovereign identity.

A Verifiable Credential (VC) is a tamper-evident digital claim with cryptographic proof of its issuer, as defined by the W3C standard. SBTs are an on-chain, tokenized implementation of VCs. Nesting allows SBTs to reference other SBTs (VCs), creating composite credentials—like a university degree SBT that nests individual course completion SBTs—while preserving cryptographic verifiability of the entire chain.

An attestation is a cryptographic statement made by one entity (the attester) about another (the subject). In SBT systems, each SBT is an on-chain attestation. Nesting establishes a graph of attestations, where a parent SBT attests to the aggregate meaning or validity of its nested child SBTs. This creates provable reputation graphs where trust can be computed across linked attestations.

In blockchain, composability is the ability for different protocols and applications to seamlessly interact and build upon each other's outputs. SBT Nesting is a form of data composability for identity. It allows protocols to:

• Read nested SBT structures from a Soul.
• Write new SBTs that reference or attest to existing ones.
• Enable complex, interoperable reputation systems across DeFi, DAOs, and governance.

SBT Nesting creates a directed acyclic graph (DAG) or tree structure of tokens, where relationships are defined by parent-child links. This is distinct from a simple list of SBTs. Key properties include:

• Non-Circular: An SBT cannot nest itself, directly or indirectly.
• Verifiable Paths: The provenance and validity of each nested link can be cryptographically verified.
• Selective Disclosure: Souls can reveal specific sub-graphs of nested SBTs without exposing their entire identity graph.