Wow this is awesome, Thank You so so much for building things like this!! All projects should use this, I know I’ve passed on many airdrops/claims before bc of not trusting the process! Also I appreciate all your threads and newsletters, I have learned so much from best security practices to how smart contract’s actually work, invaluable info and I greatly appreciate that Ser, Thank you!
I really enjoyed browsing the GH repo, looks very nicely written so kudos! Looks like you guys have stuck nicely to "do one thing really well".
I'm am really looking to some of the upcoming contract samples that you mentioned.
At the risk of sounding a bit foolish, I was hoping you could clarify my understanding of the workflow:
From what I can see: the user grants a specific permission, this is hashed and stored in the registry. At this point, permission isn't actually granted for an application to do anything (this is a registry of course), so a contract should be doing something like:
1. Querying the registry - using the helper getters
2. If a delegation permit is found for the address/contract/token, we know the user has given approval for Wallet B to interact on behalf of Wallet A
3. Let's say my contract has a method to allow user to claim an airdrop if they have an NFT. I would see that:
-- Wallet B does *NOT* have the NFT
-- Wallet A *DOES*
-- Wallet B is a delegate for Wallet A
-- I can treat Wallet B as Wallet A for the purposes of my application, so long as permission is not revoked.
That's correct! Will be releasing a sample consumer NFT contract in the coming days. The delegation registry simply stores delegations, also need to check that the underlying vault has the NFT it's delegating out.
Thanks for designing, better safety is much needed! What happens if a delegated NFT is later sold? Would the delegation expire automatically or do airdrop contracts need to add a check for this case?
Great question! Delegations don't expire unless explicitly revoked (which can be done in a single tx). So airdrop contracts need to check that the vault owns the token that the delegate is acting on behalf of
Love this and have been messing around! One thing is I have assets in my hot wallet ( that are unique from assets in my cold wallet) and it is also my delegated wallet. I notice that the hot wallet doesn't pick up hot wallet assets when connecting to collab land via delegate or doing other things- is this by design?
Wow this is awesome, Thank You so so much for building things like this!! All projects should use this, I know I’ve passed on many airdrops/claims before bc of not trusting the process! Also I appreciate all your threads and newsletters, I have learned so much from best security practices to how smart contract’s actually work, invaluable info and I greatly appreciate that Ser, Thank you!
It’s hard to exaggerate the importance of such a project.
I really enjoyed browsing the GH repo, looks very nicely written so kudos! Looks like you guys have stuck nicely to "do one thing really well".
I'm am really looking to some of the upcoming contract samples that you mentioned.
At the risk of sounding a bit foolish, I was hoping you could clarify my understanding of the workflow:
From what I can see: the user grants a specific permission, this is hashed and stored in the registry. At this point, permission isn't actually granted for an application to do anything (this is a registry of course), so a contract should be doing something like:
1. Querying the registry - using the helper getters
2. If a delegation permit is found for the address/contract/token, we know the user has given approval for Wallet B to interact on behalf of Wallet A
3. Let's say my contract has a method to allow user to claim an airdrop if they have an NFT. I would see that:
-- Wallet B does *NOT* have the NFT
-- Wallet A *DOES*
-- Wallet B is a delegate for Wallet A
-- I can treat Wallet B as Wallet A for the purposes of my application, so long as permission is not revoked.
Is that correct?
That's correct! Will be releasing a sample consumer NFT contract in the coming days. The delegation registry simply stores delegations, also need to check that the underlying vault has the NFT it's delegating out.
Much obliged. So there's a huge network effect to be tapped into if we take advantage of this new infrastructure.
Time to play around a bit!
Thanks for designing, better safety is much needed! What happens if a delegated NFT is later sold? Would the delegation expire automatically or do airdrop contracts need to add a check for this case?
Great question! Delegations don't expire unless explicitly revoked (which can be done in a single tx). So airdrop contracts need to check that the vault owns the token that the delegate is acting on behalf of
"You might just help save an ape one day…" 😆🦧
This was clearly and concisely written for readers from all types of technical backgrounds. Well done! 👏🏻
Love this and have been messing around! One thing is I have assets in my hot wallet ( that are unique from assets in my cold wallet) and it is also my delegated wallet. I notice that the hot wallet doesn't pick up hot wallet assets when connecting to collab land via delegate or doing other things- is this by design?
Gm
Is there any way to contact you for a smart contract?
Possibly! DM on twitter
Already sent a couple. I'm wondering if you received any?