delegate.cash

An immutable primitive to safely claim airdrops for vaulted NFTs

“I been hacked. All my apes gone” - the desperate cry heard ‘round the twitter, inspiring its own canonization into the meme hall of fame. Crypto infrastructure is still in its 1980’s Unix stage of life, where one wrong click can “rm -rf” your entire portfolio. Transaction simulation is primitive at best, so nontechnical wallet users can feel helpless when executing transactions. It’s scary to interact with airdrop promises, not knowing whether that tantalizing “Claim” button will (1) give you free money or (2) rug and steal your prized NFTs. For the average crypto user, it’s metaverse russian roulette.

Self-custody can be painful for inexperienced users

So what can users do? There’s great advice in this punk6529 thread to move down the spectrum of hot software wallets -> hot hardware wallets -> cold hardware wallets -> multisigs. This is good advice if you own an XCOPY or Fidenza that’s unlikely to require interaction. But what happens when you stick your bored ape into your cold hardware wallet and then Yuga says, “fuck it, mutants saturday”? How do you claim your ApeCoin? How do you get a ticket into ApeFest? How do you prove wallet ownership to access that private Discord channel? Each of these require using your so-called cold wallet to interact, turning it back into a hot wallet.

The coldwallet vault can delegate airdrop claiming powers to a hotwallet without endangering the original token.

That’s why we built delegate.cash, a fully immutable onchain registry contract that lets users specify hotwallet “delegates” to act on behalf of coldwallet “vaults”. It’s live today on Ethereum+Polygon+Goerli, with other chains available on request. The finalized contract is deployed & verified at 0x00000000000076A84feF008CDAbe6409d2FE638B for all deployments. This is a global singleton deployment, all integrations will simply query the existing delegation registry rather than needing to deploy their own. Both the smart contract repo and delegation frontend repo are open-source.

Comparison of user flows. Because the user only has to delegate their coldwallet once on a trusted site, they can then reuse that delegation an unlimited number of times for hotwallet interactions.

How does it work for NFT holders?

You’ll use https://delegate.cash to assign a hotwallet delegate for your coldwallet vault. The delegate has permission to claim airdrops or other utility on behalf of the vault, but it cannot touch anything within the vault. We’ve built a granular permissions system, so you can either assign a delegate for either (1) everything; (2) a specific contract; (3) a specific token. I expect most users will be interested in delegating everything, but you could also delegate one hotwallet to handle your bored apes claims and another wallet to handle your digidaigaku claims for further separation of powers.

How does it work for NFT devs?

The delegation registry smart contract is 100% onchain enumerable, so no need for messy event parsing, you can simply query read methods on the smart contract itself. Head over to the open-source repo for detailed explanations of the source code. We’ll also be shipping a JavaScript SDK in coming weeks to make your life even easier.

When you’re writing your NFT smart contract, you’ll want to query the DelegationRegistry contract to see if a specific user has permissions to act on behalf of a specific token.

When you’re writing your NFT frontend, you’ll want to query the DelegationRegistry smart contracts to see which coldwallet vaults a hotwallet might be eligible for claiming on behalf of.

Astute observers may have noticed that delegate.cash is not NFT-specific! In fact, we explicitly designed it to work across a wide suite of needs, including ERC20 token delegation and wallet-level reputation. While this launch article focuses on NFT adoption use cases, look forward to further creative ideas that leverage other aspects.

If you need any assistance or guidance, feel free to reach out in a Twitter DM or file a GitHub issue! We’ll also be publishing sample integrations, and I’ll be launching an onchain battle royale that integrates delegate.cash for the minting flow. There’s plenty of support!

The Competition

The most common question by far: “Why delegate.cash, why not [other delegation implementation]?”

Sincere appreciation for everyone who's taken a crack at this problem in the past with different tradeoffs. Comparison is done not to denigrate, but with the goal of hitting the best unified standard for mass adoption. That said, delegate.cash is far superior to any existing solutions, it’s not even close.

• why not ENS delegation via EIP-5131? Requires constant renewal and capital requirements, also a dangerous dependency on possible governance actions.

• why not wenew’s HotWalletProxy? Has centralized admin control, the contract is dangerously upgradeable, and only does wallet-level delegation without supporting contract- or token-level delegation.

• why not TokenProof? delegate.cash is complementary, not competitive, to mobile apps which focus on providing authentication QR codes, our registry is focused on full onchain enumerability that could even hook into TokenProof verification.

Features

delegate.cash is fully onchain, enumerable, immutable, independent, and verifiable.

• Fully Onchain

  There are no offchain signatures floating around a hidden relay network. This gives users important assurances that what you see is what you get. Attack vectors like the OpenSea stale listings problem are prevented.

• Fully Enumerable

  We provide onchain methods to get a complete list of all delegations for both cold and hot wallets. No event parsing needed. This greatly simplifies integration efforts for both smart contract and frontend developers.

• Fully Immutable

  There are zero admin powers. Because governance is an attack vector, there should be none of it in a neutral trustless delegation standard. The standard is designed to be as flexible as possible, but upgrades are always possible by deploying a new registry with different functionality.

• Fully Independent

  There are zero external dependencies, so the attack surface is locked down and the registry can deployed on any EVM chain of your choice.

• Fully Verifiable

  By using vanity addresses for CREATE2 deployment, the contract can be permissionlessly deployed at the same 12-leading-zeros address across multiple chains. This makes it easier for end users to verify that they’re interacting with the correct contract.

FAQ

Isn’t this a high-friction UX? On the contrary, should be lower-friction! Instead of digging your coldwallet out of storage every time, you can delegate once on delegate.cash and then use your hotwallet for all future interactions.

How do we know which apps to trust? That’s the beauty, you don’t have to! Since you’re only interacting with a throwaway hotwallet, it’s much safer to claim experimental airdrops or handle other interactions as the hotwallet doesn’t have anything of value to steal. The only trust requirement is checking that delegate.cash matches the deployed contract, and that the deployed contract code is honest. That only needs to be checked once.

How can a dapp trust that the delegate was verified by the vault? Since the singleton delegation registry deployment is fully onchain enumerable, you can query the read methods directly (more detail in the repo itself).

So What?

If you’re a dev team, go build on it! This is neutral public infrastructure with significant convex upside from multiple teams adopting it. If Team A and Team B both decides to use delegate.cash for their upcoming airdrop, then A holders can reuse existing delegations to interact with B. There are convex network effects to registries similar to those in liquidity bootstrapping, and helping your holder base avoid common scams by helping them keep their coldwallet vaults in storage is a great gift.

If you’re an NFT holder, advocate for your favorite team to adopt this standard! You might just help save an ape one day…

Resources

smart contract repo: https://github.com/0xfoobar/delegation-registry
frontend repo: https://github.com/0xfoobar/delegate-cash-frontend
smart contract deployment: 0x00000000000076A84feF008CDAbe6409d2FE638B
frontend deployment: https://delegate.cash
EIP-5639: https://eips.ethereum.org/EIPS/eip-5639
npm sdk: coming soon