Loss of CDT to the SSV token upgrade contract

[gob]

Summary of Proposal

Dear All,

This proposal is about an honest mistake that was made during the process of a token upgrade of CDT to SSV.

CDT tokens were sent to the SSV token upgrade contract with a “Transfer” function instead of “Convert” function, thus making those CDT tokens lost in the contract without the issuance of new SSV tokens back to the sender’s address as should have been.

The transaction was made a few months ago, and can be seen below:

Ethereum Transaction Hash (Txhash) Details | Etherscan

Why was this mistake made?

SSV documentation stated that “A simple CDT deposit into the TokenUpgrade contract will send SSV tokens back to the sender”. I later found this not to be true.

Source: Snapshot

Proposal Details

My proposal is basically to allow the SSV DAO to mint new tokens and send the newly minted tokens back to the sender’s address (0x697302628be3dd222da2c817b405c561ac25fdea) the appropriate amount according to the original CDT → SSV token upgrade process.

According to the above mentioned transaction, a total of 214,691 CDT tokens were transferred to the SSV contract, which applies for 2,146.91 SSV tokens (1:100)

So a total of 2,146.91 SSV tokens should be minted and issued to the address 0x697302628be3dd222da2c817b405c561ac25fdea

The CDT tokens are effectively burned as there is no way to withdraw them from the contract.

Token Upgrade CDT -> SSV

Token Upgrade Status: unassigned Proposal Overview We propose to enable a voluntary upgrade of the CDT token to a new ERC20 contract, symbol, decimal precision and minting ability. The name of the upgraded token will change to SSV. Motivation CDT was developed in 2017 using best practices and latest standardized code by the leading libraries (OpenZeppellin). Many innovations, repairs and advancements have been made to said code which should be updated to the current CDT token contract. A…

Non-technical ELI5 of proposal

A total of 2,146.91 SSV tokens should be minted and issued to the address 0x697302628be3dd222da2c817b405c561ac25fdea due to wrongly sent CDT tokens to the ssv token upgrade contract which are now lost in the contract.

Motivation for Proposing

An honest mistake was made due to unclear language in official documentation. This proposal seeks to rectify this mistake, your support is highly appreciated

Reasons supporting the proposal

A mistake was made due to misleading documentation, let’s fix it. Circulating SSV supply will not be affected as the tokens are locked forever in the conversion contract.

Reasons against the proposal

Total supply will increase by a miniscule amount. (No change to circulating supply as tokens are locked forever in the conversion contract…)

[fod]

I support trying to help you out, as these kinds of mistakes happen. But this seems suspicious. I would need some people that are much more knowledgeable than me to verify that there’s no risk of a scam here.

Why didn’t you use the token conversion page here?

[gob]

Thank you fod for your support.
I should have followed the token conversion page, but when i first searched in google for a way to swap the tokens, i have came across Adams post proposal here:

Token Upgrade CDT -> SSV

Token Upgrade Status: unassigned Proposal Overview We propose to enable a voluntary upgrade of the CDT token to a new ERC20 contract, symbol, decimal precision and minting ability. The name of the upgraded token will change to SSV. Motivation CDT was developed in 2017 using best practices and latest standardized code by the leading libraries (OpenZeppellin). Many innovations, repairs and advancements have been made to said code which should be updated to the current CDT token contract. A…

And as you can see, it was said that a simple deposit to the token upgrade contract will send back the sender SSV tokens. this is why i have transferred the tokens.

this is not a scam, why should it be and how could it be a scam?

[fod]

Ok, thanks for the clarification, and sorry for the slow response. It makes sense that if you weren’t following the project’s news, you could have easily been unaware of the swap page.

And please don’t take offense… I’ve encountered way too many sophisticated scams that look benign on the surface, so I think caution is always smart in this space. I just think this should be checked by someone who thoroughly understands those contracts (I do not).

I think the community should be willing to help you out though. And you’re lucky that we have another similar request to return funds that were sent to the DAO treasury by mistake (Fundamental Labs Refund Request). Both that request and yours will have to be approved by a vote, and maybe we can just combine the two requests into a single vote to help get them enough votes to be passed.

[gob]

Hey Fod, thanks for the reply,

No offense taken and your concern is understandable.

Your suggestion with combining both proposals sounds perfect as I also support the returning of the funds to Fundamental Labs.

Once again, highly appreciate your support.

[fod]

The vote failed to meet the quorum, which is currently about 346k SSV. We can vote on this again, but before you make the snapshot, I would coordinate with the community first so we can try to encourage more people to vote.

Also, one small complication with this… after looking into the conversion contract, there is no withdrawal function that we can use to retrieve your funds (this was intentional). So it seems like the only way is to mint new tokens and send you those. I would edit the proposal to state that minting tokens will be required… and I would be clear that the tokens you sent are effectively burned, so the net supply change is zero.

[gob]

Hey fod, thanks for your reply and input.
Apologies for my late reply on this matter as i’ve been busy with other personal issues.

I would like to try to vote on this again, hoping to bring the community attention to this as this is highly important to me.

[gob]

A bump in the post and a minor update to the original post was made.

[BenAffleck]

Unfortunately, the vote didn’t reach the minimum quorum.

https://snapshot.org/#/mainnet.ssvnetwork.eth/proposal/0x60cc87fb5f5f4a74ef6021f0f1b0a5fed3743bcb13de3e56fb3ea06053f0cbc1

[gob]

Hey Ben, thanks for the update. Yes i have noticed that.
it was disappointing to see other proposals pass while this one didnt.
It makes you wonder about the intentions of the community…

[irina-everstake]

Hello everyone! I can see another Snapshot voting regarding this issue.

Is it from the affected user or initiated by some scammer (identity pretender), as I see that an address that created this Snapshot differ from those in the previous voting from the user?

Current voting:

Previous one:

[BenAffleck]

Good catch! I think this is the case, the person was trying to catch the current batch and hope for participation.

Since the proposal in itself is valid, everyone is invited to vote again. AFAIK, the DAO doesn’t have a policy that prohibits this approach (maybe it should).

I’ve voted.

[kbc]

Looks like the third try

Always with recipient as 0x697302628be3dd222da2c817b405c561ac25fdea and amount 2,146.91 SSV

If they haven’t passed the quorum the first two times, what are they doing differently this time to pass the quorum?

[BenAffleck]

Nothing. Trying to catch the train with so many other proposals online recently.

We should have a resubmission policy in place. Noted, but maybe not a top priority for now.

Thanks for sharing your thoughts, @kbc!