Delegate.cash

At its heart, Delegate.cash is a delegation registry—a single, shared smart contract that maintains a public, on-chain record of delegations. A wallet (the delegator) can register another wallet (the delegate) to act on its behalf for specific NFTs or token types. This creates a permission layer without transferring ownership.

• Vault Wallet Pattern: Users keep valuable assets in a secure cold wallet (vault) and delegate usage rights to a separate, more frequently used hot wallet.
• On-Chain Verification: Any integrated application can query the registry to check if a connecting wallet has valid delegated rights for a specific NFT.

The protocol offers three granular levels of delegation scope, providing flexibility for different security and use case needs.

• Contract-Level Delegation: The delegate can act for all NFTs from a specific collection owned by the delegator. Useful for full management of a collection.
• Token-Level Delegation: The delegate is authorized for a specific, single NFT (by token ID). Ideal for lending or temporary, precise permissions.
• All-Encompassing ("For All") Delegation: The delegate can act for all NFTs across all contracts owned by the delegator. This is the highest-trust mode, often used for complete wallet management by a trusted party.

The dominant use case is separating asset custody from daily interaction, significantly improving security posture.

• Cold/Hot Wallet Setup: Users store high-value NFTs (e.g., Bored Apes, CryptoPunks) in a hardware wallet (cold) but delegate the rights to a hot wallet (like MetaMask) for activities like voting, staking, or displaying in a profile.
• Risk Mitigation: The hot wallet can be compromised without risking the loss of the underlying assets, as it only holds permissions, not ownership. The delegator can revoke access at any time.

Hundreds of decentralized applications (dApps) have integrated Delegate.cash to respect delegated rights, unlocking functionality for vaulted assets.

• NFT Marketplaces: Platforms like Blur and OpenSea check the registry. A delegate can list, make offers, or buy on behalf of the vault wallet.
• Gaming & Metaverse: Games like Parallel and Pudgy Penguins allow delegated wallets to use in-game assets stored in cold storage.
• Governance & Social: DAOs and social platforms (e.g., Galxe) recognize delegates for voting or proving community membership via held NFTs.

Delegations are non-custodial and revocable at any time by the asset owner (delegator). This is a core security feature.

• Immediate Revocation: The delegator submits a transaction to the registry to remove a delegate's permissions. This change is effective immediately for all integrated applications.
• No Trust in Operators: The Delegate.cash contract is immutable and permissionless. There is no admin key or centralized party that can alter or seize delegations.
• User-Controlled: Security ultimately depends on the security of the delegator's private key.

Delegate.cash and Account Abstraction (ERC-4337) address related problems—improving wallet usability and security—but through different architectural layers.

• Delegate.cash: Operates at the application logic layer. It's a specific smart contract that dApps choose to query for permissions. It works with any standard Externally Owned Account (EOA).
• Account Abstraction: Operates at the protocol/account layer. It replaces EOAs with smart contract wallets that can natively encode complex logic, like spending limits or multi-sig, directly into the account itself.
• Synergy: A smart contract wallet (ERC-4337) could be set as a delegator in Delegate.cash, combining the benefits of both approaches.

Delegate.cash defines three delegation scopes, each with a distinct security profile:

• Contract-level: Delegates can interact with any contract on behalf of the vault. This is the most powerful and risky scope.
• Token-level: Delegates can interact with specific token IDs (e.g., Bored Ape #1234). Limits exposure but requires precise management.
• Wallet-level: Delegates can act for all tokens in the vault. Broad utility but increases the blast radius if a delegate is compromised. Understanding the scope is critical for assessing the permissions being granted.

Security depends on the ability to revoke access. Delegate.cash offers two primary methods:

• Direct Revocation: The vault owner can instantly revoke any delegation. This is the standard and safest model.
• Expiring Delegations: Delegations can be set with a block number expiration. After the specified block, the delegation automatically becomes invalid. This is useful for temporary, trust-minimized access. A key consideration is that revocations are not retroactive; any transactions signed by the delegate before revocation may still be valid if included in a later block.

The system creates two distinct threat models:

• Vault Private Key Compromise: If an attacker gains control of the vault wallet, they can revoke all legitimate delegations and create new, malicious ones. This is a catastrophic failure equivalent to losing the assets.
• Delegate Private Key Compromise: If a delegate's wallet is compromised, the attacker gains the delegated permissions but not ownership of the vault's assets. The vault owner must revoke the delegation to neutralize the threat. The risk is scoped to the permissions granted (e.g., only staking, not selling).

The security of the entire system depends on:

• Delegate.cash Registry Integrity: The immutable, audited core contract that maintains the delegation list.
• Integrating Protocol's Validation: Any protocol accepting delegations must correctly query the registry. A bug in the integrator's code could allow unauthorized actions.
• Front-running Revocations: In a mempool, a malicious delegate could see a revocation transaction and attempt to front-run it with a malicious transaction using their soon-to-be-revoked permissions. Users should consider using private transactions (e.g., Flashbots) for critical revocations.

Delegation introduces new phishing vectors:

• Fake Delegation Requests: Users may be tricked into delegating to a malicious address, granting it permissions to interact with their assets on integrated platforms.
• Impersonation of Trusted Delegates: Attackers may create wallet addresses similar to well-known delegate services (e.g., gaming guilds, rental platforms).
• Signature Farming: Malicious dApps may request signatures for transactions that inadvertently create a delegation. Users must verify exactly what they are signing, as a delegation signature grants ongoing permissions, not just a one-time transaction.

A delegation registry is a smart contract that maintains a mapping of delegations from a vault address (owner) to a delegate address for specific token contracts or token IDs. Delegate.cash is a specific, gas-optimized implementation of this concept. Its core functions are:

• delegateForAll(contract, delegate): Grants access to all NFTs in a collection.
• delegateForToken(contract, tokenId, delegate): Grants access to a specific NFT.
• checkDelegateFor...: Permission-viewing functions for other contracts to query.

A vault wallet (or cold wallet) is a highly secure address where assets are stored long-term, typically with limited signing capabilities. In the Delegate.cash model:

• This is the delegator—the address that owns the NFTs and creates the delegation.
• It remains the sole owner on-chain; tokens are never moved.
• Its private keys are kept offline, minimizing exposure to hot wallet risks while still enabling utility of the assets.

A hot wallet is a software-connected address used for frequent transactions and interactions with dApps. With Delegate.cash:

• This acts as the delegate—the address authorized to use the vault's NFTs.
• It can sign transactions to interact with gaming, minting, or social dApps on behalf of the vault.
• If compromised, the attacker only gains delegated rights, which can be revoked by the vault, leaving the underlying assets secure.

Token-gated access is a mechanism where entry to a website, Discord server, or smart contract function is restricted to holders of a specific NFT. Delegate.cash enables this for vault owners by:

• Allowing dApps to check checkDelegateForAll or checkDelegateForToken instead of just ownerOf.
• This lets the hot wallet (delegate) gain access while the NFT remains secured in the vault.
• It is the primary use case for the protocol, separating asset custody from asset utility.