Custody Models in Web3
The terms self-custody, custodial, non-custodial, and others alike are casually thrown around in the industry by different products and protocols, leading to misunderstandings and a subsequent erosion of trust. It's high time we address and rectify this issue.
The security and autonomy provided by different custody solutions are often contingent on the role of the 'signer'. A signer is an entity or mechanism authorized to approve transactions, which can vary from automated smart contracts to end-users themselves.
Role of a Signer
Within your gaming application, the signer holds a key position as the gatekeeper of a player's smart account. Its duties encompass:
- Safeguarding the private key, which is the vault to a player's digital assets.
- Verifying player identity to ensure legitimacy of actions.
- Shielding the account from unauthorized access and phishing attempts.
- Executing transactions and operations, contingent on player authentication.
- Providing optional account recovery solutions to maintain accessibility even in contingencies.
Signers and Custodians
| 👤 Self custody | ⚙️ Self-managed custody. | 🏦 Institutional custody. | |
|---|---|---|---|
| Private Key Technology | User-generated and controlled. Typically, keys are generated by the device or software the user controls (e.g., hardware wallet). | User controls the generation but may rely on external, less controlled infrastructure for storage or management (e.g., MPC, DKG, etc.). | Managed by the third party. Keys are typically generated and stored on secure, institutional-grade servers. |
| Private Key Visibility | Full visibility to the user. The user can directly access and view their private keys. | Limited visibility. The user might not directly view the keys but controls the environment in which they are used. | No direct visibility. The private keys are not accessible to the user; instead, they are held by the institution. |
| Private Key Control | Full control by the user. They decide when and how the keys are used. | The user retains control over the use of keys but doesn't manage the full lifecycle or infrastructure. | Limited to no control. The institution manages the use and application of keys. |
| Private Key Recovery | User is responsible for backup and recovery solutions. They must create and manage secure backups of their keys. | Mixed responsibility. The user may need to manage backup solutions, but some support might be available from the service. | Mostly managed by the institution. The institution often provides backup and recovery processes as part of their services. |
| Examples | The most popular are wallets like Ledger, Trezor, MetaMask, etc. | Some examples include Zengo Wallet, Dfns, Fireblocks, Turnkey. | Some examples include Coinbase, BitGo, Bitcoin Suisse AG. |
Security Implications
1. The Importance of a Robust Security Model
When integrating wallets into Web3 games, the chosen security model can have far-reaching implications for both players and developers. It's essential to consider where and how private keys are stored. For instance, are they on a user's device, secured in the cloud, or with a third-party provider?
The encryption of private keys is another critical factor, with questions about the type of encryption algorithm used and who holds the decryption keys being paramount. These considerations are not just technicalities—they are the bedrock of trust in the gaming ecosystem.
2. Key Exportability and Recovery Options
The ability for players to export and recover their keys is another cornerstone of wallet security in gaming. Gamers need assurance that they can export their private keys, ensuring control over their assets regardless of the game's status or service provider's health.
Moreover, should a player forget their credentials or lose access to their device, the recovery processes provided by the wallet can mean the difference between a temporary setback and a permanent loss. Game developers must prioritize these features to support their players’ asset security.
3. Service Provider Continuity
The reliability of a signer service provider is critical. If the provider faces downtime, what happens to the players? Can they still sign transactions and access their in-game assets? In a dynamic gaming world, interruption in these services can break the immersion and potentially disrupt the game's economy.
Criteria Selection in Gaming
To properly evaluate each model, we need to understand the following concepts:
- 🔑 Private key/seed generation. Where are the underlying keys managing the assets being generated? Are they generated in a secure, trusted, isolated environment? - 📥 Key material export. Is access to the underlying cryptographic primitives allowed? Can they be exported securely? - 🔐 Backup generation. Can we generate backups for the private keys in a secure, encrypted way? - 🔓 Backup verification. Can backups entirely restore the account in which the assets are being stored?
Conclusion
Each strategy has its drawbacks. Giving more control to the user includes more responsibility but provides the most power with the least cost. The least amount of control comes at a higher price, yet it includes additional features such as insurance. Sometimes, you always have access to the private key (e.g., self-custody), but you need to handle backups yourself. If backups are not provided, then we need to guarantee that the custodian has enough controls in place to verify these themselves.
As we build Openfort, we're striking a across all these strategies around self-custody in gaming. We believe the best approach is having a flexible ownership model that offers a standardized player experience across the different types of ownership models. At Openfort we advocate for embedded smart accounts as the optimal solution to onbaord people into games.
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.