Technical Dive: Combining Token Bound Account (TBA) with Account Abstraction (AA)

Understating the ERC-6551

ERC-6551 is an Ethereum standard that allows ERC-721 tokens to have their own smart contract accounts, also known as Non-fungible Token Bound Accounts (TBA). This means that NFTs can now own digital assets and interact with various applications. The system doesn't require any changes to existing ERC-721 NFTs.

The ERC-6551 mechanism consists of three key parts: a registry, an account interface, and a minimal proxy implementation. The registry is permissionless and immutable, and it deploys a smart contract account for an NFT.

The account interface sets the standard process, rules, and limits for account creation. ERC-1167 minimal proxy contracts are used in deploying accounts, making account implementations much easier and cheaper.

ERC-6551 is an improvement over ERC-721 because it overcomes some of the limitations of ERC-721. ERC-721 tokens are static and can only show static data or information. They are also not composable and cannot interact with other on-chain assets or contracts independently. ERC-6551, on the other hand, maintains backwards compatibility with previously minted ERC-721 NFTs and deploys smart contract accounts for NFTs via a permissionless registry.

Check the technical ERC-6551 proposal as well as the non-technical write up from the authors.

The Gaming Use Case for ERC6551

Before ERC6551

In a traditional gaming application, players could own their characters as ERC-721 NFTs. However, all related assets that they collected within the game would also sit as separate tokens in the owner's wallet. This could be inconvenient for players, as they would have to keep track of multiple tokens and manually transfer them between their character and their wallet.

Additionally, it would be difficult for game developers to create in-game UIs that allowed players to easily manage their assets.

With ERC6551

ERC6551 allows game developers to create "inventories" for players. This means that all of a player's game-related assets can be automatically transferred into their character's wallet. This makes for a better user experience, as players no longer have to keep track of multiple tokens.

Additionally, it allows game developers to create in-game UIs that are much more user-friendly.

For example, imagine a game where players can collect different weapons and armor. With ERC6551, players could simply equip their weapons and armor directly from their character's inventory. This would make the game more immersive and engaging, as players would no longer have to switch between their wallet and the game UI to manage their assets.

Benefits of ERC6551 for gaming

ERC6551 offers a number of benefits for gaming applications, including:

• Improved user experience: ERC6551 makes it easier for players to manage their game-related assets. You can now create a smart account via a minted or airdropped NFT
• Enhanced gameplay: ERC6551 can be used to create more immersive and engaging gameplay experiences. For example, players could use ERC6551 to equip their characters with different weapons and armor, or to purchase items from in-game shops.
• Increased security: ERC6551 can help to improve the security of game assets. This is because token-bound accounts are more secure than traditional wallets (EOAs). Overall, ERC6551 is a valuable tool for gaming applications. It can be used to improve the user experience, enhance gameplay, and increase security.

Challenges and Limitations of ERC-6551

While ERC-6551 brings a new layer of functionality to NFTs, it also introduces a set of challenges and limitations:

1. Complex NFT User Experience: ERC-6551 adds additional features and capabilities to NFTs, which also brings a new layer of complexity. Users need to have a higher level of understanding to fully utilize these advancements.
2. Implementation Complexity: Implementing the ERC-6551 standard into existing ERC-721 tokens requires creating and configuring a new smart contract. This process can be complex and requires technical expertise. Additionally, it may involve paying for the services of a blockchain developer.

At Openfort we want to overcome these challenges by smoothing and standardizing the interactions directly via APIs, offering an already build implementation catered towards web3 gaming.

Let’s see how we’ve done this.

Combining the ERC6551 and ERC4337

The creation of smart wallets within in-game assets represents a leap forward into the evolution of the player experience in the game. No longer the standard unlocks new utility for NFTs but also allows for composability with other standards, in this case the famous ERC4337 (Account Abstraction).

At Openfort, we looked at the different ways we can combine them together to untap novel use cases while enjoying an optimal player experience. Here are the findings and thoughts as well as the path to follow if you’re looking to implement and offer “wallet-less” experience to your players.

Option 1: NFT is owned by an Openfort 4337 account

The first option drops an ERC721 into a newly created smart wallet with Openfort. The ERC721 is 6551 compatible allowing it to store the different in-game assets, while the interactions happen at the Openfort level (4337 compatible) ensuring there is a smooth player experience -gasless txs and zero txs prompts.

Nevertheless this option has constraints because the actions need to be encoded before sent and get the new owner form the logs via the implementation ABI. All in all:

• (+) It uses session keys, which can enable a popup-less experience for users.

• (-) You deploy two smart wallets making it more costly to interact.

• (-) While the implementation works with Openfort it is cumbersome to use via the API.

See the implementation in our Github repository.

Option 2: NFT is owned by an EOA and EIP6551 account is EIP4337 compliant

This option reduced the complexity of the implementation, because now you don’t need to deploy two smart contract wallets but rather make the TBA compatible with ERC4337 directly while the EOA has the ERC721 ownership.

The main disadvantage here is that you need to be careful the way you apply session keys within the game in the case an NFT owner decides to transact their token.

All in all:

• (+) It reduces the complexity of the solution while also lowering the gas spending (you only create one smart wallet instead of two).
• (~) You can still benefit from session keys in your game but need to make sure to revoke them if the NFT is transferred to a new owner.

See the implementation in our Github repository.

How can I use Token Bound Accounts with Account Abstraction?

Openfort’s 4337 account and a 6551 account are quite similar. The main difference is that the ownership of the 4337 account is defined by who has the signer and the ownership of the 6551 account is defined by who has the NFT.

Both have therefore the option of transferring ownership.

• For the 6551 account, approve and transfer the ownership of the NFT.
• For the 4337 account, request and accept ownership of the account.

While both options are doable we recommend following the second implementation better. It’s natively supported via our endpoints and ensures a smooth player experience as long as we implement the revocation of session keys is needed given a change of ownership of the NFT (we can help with that). You can check the ERC6551 smart contract here.

If you have more questions/ideas/queries, join our Developer Discord and let us know there. Furthermore, you can follow us on Twitter for our updates as we keep shipping.