What is the best approach (if any) to request $SAFE tokens from the SafeDAO claim for wallets I no longer have access to AND that I am the owner of?
A potentially related post was made on 2022-10-18.
I have a total of 3 Safes that I used for temporary testing and I no longer have access to. I used these Safes without planning to have long-term access to them. The tests covered were moving assets on and off of the addresses, using different wallet types, and recovering the Safe using seed phrases after deleting all Safe apps and wiping all wallets. I did not save the seed phrases for the test co-signer wallets as I was not considering this future scenario in the summer of 2021.
Submit a formal SEP proposal for the quantity of SAFE tokens I no longer have access to claim, but I am the owner of these addresses?
a. This may cause many others to submit similar SEPs. I’m wondering if there is a more effective approach as to not create many individual SEPs.
Do nothing and be happy.
For Safes that have unclaimed $SAFE tokens after the claim deadline and have users that are stating they previously owned these Safes in question and are not recoverable, one cannot prove ownership. As a potential workaround a user could show PoA.
- A user proves they’ve deposited and withdrawn assets with the Safe in question.
- Record a screen share video without showing sensitive info that showcases the outflow and inflow to the Safe in question with an address/exchange they provably own.
- E.g. Sign into Coinbase account or MetaMask wallet of provably owned address to show transaction history of outflow and inflow with the Safe in question.
In my case of using Safes for testing I made small deposits into the addresses below and can show PoA with these addresses.
The total amount to potentially claim is 998.97 $SAFE.
That certainly sounds like an edge case that wasn’t considered in the current allocation and claim process. Would be interesting to get a sense how many more Safes fall into the same category.
Your suggested options are on point when you say that, surely, there’ll be more requests or proposal of similar nature coming up around and after the claiming deadline on Dec 27. Simply missing the deadline shouldn’t be an excuse that the DAO will want to accept, but cases like yours do seem worth considering.
Though I’d suggest we keep them separate from the existing allocation process and claim period, which has been announced as follows:
Claims can be made until December, 27th 2022 at 12:00 PM CET, after which any unclaimed tokens will be returned to the DAO treasury.
Separately, SafeDAO could consider a new SEP to propose a set of token allocations. We could use this thread to gather feedback on Safe users facing the same or similar issues with the airdrop.
Thanks for the response! I’m glad to hear that the suggested options make sense and are worth considering.
I’ve updated the original post with a potential solution, “proof-of-access” for users making claims to verify that they are the ones who deposited and withdrew from the Safes in question.
From my previous thread, indeed some of the options you mentioned may be possible. I think the best approach would be to create a (joint?) SEP that claims these inaccessible SAFE tokens, combining the other edge cases into a single governance vote to simplify administration.
I agree a joint proposal likely makes sense in the future vs. many individual ones. It’s important all applicants in the proposal are following the same acceptance criteria as well so that all of the submitted addresses are pre-vetted before the proposal is live.
Agree, although then we should clearly differentiate the individual cases/allocations and try to get a temperature check on each of these before the proposal reaches Snapshot. Just to avoid the bulk proposal being voted down because of a single case/allocation included. We won’t have complete certainty before Snapshot but if we clearly lay out the cases in this thread and give the proposal time to be reviewed by everyone including Guardians and investors, then we’ll surely have a better idea which cases/allocations are controversial and which aren’t.
I think that this is a bad idea, if we are talking about decentralization, every time there will be losses of tokens, this is inevitable, why does no one return the lost ether or bitcoin? We must clearly state that the loss of access to the wallet, or its hacking lies on you! We are not USDC/USDT to block addresses and contracts. We are a free project first and foremost, although of course there are bad people among us who rejected SEP2 and hide behind the safe team like mice. But despite this, we must abandon the idea that lost/stolen tokens can be recovered otherwise it will bring more problems than good.
What is the difference between “an unrecoverable safe”
and someone elses safe?
More the point, how is anyone to genuinely know?
If the safe is unrecoverable then obviously they do not control the keys for it for w/e reason (genuine or nefarious alike)
If i created a safe and sold it, could i not then claim that safe is actually an “unrecoverable safe” of mine and attempt to retrieve it through this process?
How has this even being seriously considered and not just dismissed as an obvious attempt to social engineer a loophole ?
The only response to @adamhurwitz.eth?
Next time use a testnet to test. Not mainnet.
Perhaps read this 200 page guide about Crypto
bit.ly/open-coinverse-guide then you’d know better.
OH… you authored that… well… i guess you know what to put in chapter 1 of book 2.
What is the difference between “an unrecoverable safe” and someone elses safe?
Great question. This is why proof-of-access outlined above is a potential option because it shows that the user has the ability to move funds on and off of the Safe in question. It is not perfect and it would be great if there are other ideas to brainstorm too.
Next time use a testnet to test. Not mainnet.
Thank you for exploring the Coinverse guide! Using products that are available on testnet is a good process improvment moving forward.
I support having a joint proposal with the same acceptance criteria.
In regards to social engineering attacks, this is easily overcome by ensuring unvested/unclaimed tokens are no longer vested to the inaccessible safe (along with a proof of previous control / acceptance criteria). In this way, no extra supply is created and there is no doubling up.