VeChain Docs
  • Welcome to VeChain
  • Blockchain Basics
    • Introduction to blockchain
    • Introduction to digital property
    • The evolution of the internet
  • Introduction to VeChain
    • About the VeChain blockchain
      • Consensus Deep Dive
      • Governance
    • Dual-Token Economic Model
      • VeChain (VET)
      • VeThor (VTHO)
    • Acquire VeChain Assets
    • Sustainability
  • Core Concepts
    • Networks
      • Thor Solo Node
      • Testnet
      • Mainnet
    • Nodes
      • Node Rewards Programme
    • Blocks
      • Block Model
    • Transactions
      • Transaction Model
      • Transaction Fees
      • Transaction Calculation
      • Meta Transaction Features
        • Transaction Uniqueness
        • Controllable Transaction Lifecycle
        • Clauses (Multi-Task Transaction)
        • Fee Delegation
          • Multi-Party Payment (MPP)
          • Designated Gas Payer (VIP-191)
        • Transaction Dependency
    • Block Explorers
    • Wallets
      • VeWorld
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync2
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync
        • User Guide
          • Wallet
          • Ledger Device
          • Browser dApps and web
          • Interact with dApps
          • Activities
          • Settings
          • Report an Issue
          • Contributing
        • FAQ
    • EVM Compatibility
      • VeChain Modifications
      • Methodology
      • Test Coverage
        • Gas model
        • Raw transaction
        • hardhat specific
          • Ganache failures
          • evm_increaseTime
        • Failures in constructor
        • eth_sign
        • Contract address prediction
        • BadBeacon proxy address at 0x1
      • How to Recreate
      • Additional Information
        • Using Governance Contracts
        • ERC1820/ERC777 Testnet
        • Delegate Options
    • Account Abstraction
      • UserOperation
      • Bundler
      • EntryPoint Contract
      • Account Factory Contract
      • Paymaster Contract
    • Token Bound Accounts
  • How to run a node
    • Nodes
    • How to run a Thor Solo Node
    • Custom Network
    • Connect Sync2 to a Thor Solo Node
  • Developer Resources
    • Getting Started
    • How to build on VeChain
      • Connect to the Network
      • Read Data
        • Read Blocks
        • Read Transactions
        • Read Accounts
        • States & Views
        • Events & Logs
        • VET Transfers
      • Write Data
        • Transactions
        • Fee Delegation
      • Listen to Changes
        • Events
        • VET Transfers
        • Transactions
        • Blocks
        • Beats
      • Build with Hardhat
      • Utilities
        • BigInt and Unit-Handling
        • Name Service Lookups
    • Example dApps
      • Buy me a Coffee
      • Token Bound Accounts
      • PWA with Privy and Account Abstraction
    • EVM Compatibility for Developers
      • Key Architectural Differences and Optimizations
      • Practical Implications for Developers: Key Considerations
      • RPC Methods (Detailed Breakdown)
      • Frequently Asked Questions (FAQs)
      • VeChain Blockchain Specifications
      • Key Differences Between VeChain and Ethereum (Summary)
      • Best Practices for Developing on VeChainThor
    • How to verify Address-Ownership
      • Next.js Session Verification
    • Debug Reverted Transactions
    • Account Abstraction
    • VIP-191: Designated Gas Payer
      • How to Integrate VIP-191 (I)
      • How to Integrate VIP-191 (II)
      • How to Integrate VIP-191 (III)
    • Index with Graph Node
      • Setup with Docker
      • Index with OpenZeppelin
        • Create Subgraph Project
        • Configure Contracts
        • Deploy Subgraph and start Indexing
        • Track Subgraph Indexing
        • Access Subgraph
        • Update Subgraph
    • SDKs & Providers
      • SDK
        • Architecture
        • Accounts
        • Bloom Filter
        • Certificates
        • Contracts
        • Cryptography
        • Debug
        • Encoding
        • Polls
        • Subscriptions
        • Thor Client
        • Transactions
      • Thor DevKit
        • Installation
        • Usage
          • Cryptography
          • Accounts
          • Encoding
          • Transactions
          • Certificates
          • Bloom Filter
      • DApp Kit
        • v2
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
        • v1
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
          • Node Polyfills
          • V0 to V1
        • v0
          • Installation
          • Usage
          • React
            • Installation
            • Usage
          • Vanilla (UI)
            • Installation
            • Usage
          • Styles (UI)
          • i18n
      • DevPal
      • Web3-Providers-Connex
        • Installation
        • Usage
      • Connex
        • Installation
        • API Specification
    • Frameworks & IDEs
      • Hardhat
      • Remix
    • Built-in Contracts
    • VORJ
    • Useful Links
  • How to contribute
Powered by GitBook
On this page
  • TL;DR
  • Introduction
  • Token Bound Account Use Cases
  • How Token Bound Accounts Work
  • ERC-6551: Registry
  • ERC-6551: Account Interface
  • ERC-6551: Proxy

Was this helpful?

  1. Core Concepts

Token Bound Accounts

An interface and registry that allows ERC-721 and ERC-1155 tokens to have their own smart contract accounts.

The implementation of token bound accounts is work in progress. Hence, this material is subject to change.

TL;DR

Token Bound Accounts (TBAs) enhance the functionality of new and existing NFTs by equipping them with smart contract accounts. TBAs can be used to interact with decentralized applications (dApps), receive, store or transfer digital assets, either fungible or non-fungible. TBAs are backwards compatible with the ERC-721 and ERC-1155 standards, meaning existing non-fungible tokens (NFTs) can implement ERC-6551 without undergoing any fundamental changes.

Introduction

Token Bound Accounts (TBAs) allow ERC-721 and ERC-1155 tokens to have their own smart contract accounts. This means that non-fungible tokens (NFTs) can own and interact with digital assets, either fungible or non-fungible, and interact with decentralized applications (dApps). There are several implementations of the TBA standard. When we refer to TBAs were are referring to the ERC-6551 standard implementation.

Token Bound Account Use Cases

TBAs allow ERC-721 and ERC-1155 tokens to have their own smart contract account which opens a range of potential use cases:

  • Identity: Individuals can utilise a TBA enabled NFT as their on-chain identity.

  • Metaverse: By utilising a TBA enabled NFT as their on-chain identity the user can enter and interact in the metaverse as their NFT avatar.

  • Membership / DAO Management: Soul bound tokens, rewards or proof of participation (PoP) tokens are sent to the decentralized autonomous organization (DAO) TBA NFT instead of a user account.

  • Composability: A TBA can be an inventory system holding different types of digital assets. For example, you could equip an NFT with different clothing or accessories which could provide your NFT with different abilities.

  • Gaming: Your TBA enabled NFT holds your in game assets. You can customise your NFT with different gear or equipment giving it different capabilities or abilities.

How Token Bound Accounts Work

Token Bound Accounts are formalized through ERC-6551 If you wish to read more on how it works the following resources are a good starting point:

ERC-6551: Registry

The registry is permissionless and immutable, and it deploys a smart contract account for an NFT. As the EntryPoint contract is a singleton contract there only exists a single implementation and deployment of the contract on the VeChainThor blockchain mainnet and testnet networks.

Network
Address

Mainnet

0x3E9a72618b4D27c110793a76bdEE83173b9686fB

Testnet

0x6eBeed52e2BAf27B0d9763c874AbaA23cE1D134a

ERC-6551: Account Interface

The account interface sets the standard process, rules, and limits for account creation.

ERC-6551: Proxy

ERC-1167 minimal proxy contracts are used in deploying accounts, making account implementations much easier and cheaper.

PreviousPaymaster ContractNextHow to run a node

Last updated 11 months ago

Was this helpful?

Official ERC-6551 Ethereum Site