STP-1 Proposal to Refund Lost Tokens

SubQuery Foundation
1

STP-1 Proposal to Refund Lost Tokens

Author: Younessnet
Created: 2024-06-20
Status: A vote is ongoing

Motivation
The purpose of this proposal is to refund the 893,901 SQT tokens that were accidentally sent to the Ethereum SQT contract.
This refund is essential to ensure that the rightful owners regain access to their tokens and to maintain trust within the community.

Description
This proposal outlines the process for allocating the necessary capital to refund the lost tokens. The milestones for this process include:

  1. Approval of the proposal by the community.
  2. Verification of the accidental transactions.
  3. Execution of the refund to the affected addresses.

Implementation
The implementation plan involves the following steps:

  1. Verification: Confirm the transactions that resulted in the loss of 893,901 SQT tokens.
  2. Approval: Secure community approval through the Snapshot Voting process.
  3. Refund Execution: Transfer the 893,901 SQT tokens from the treasury to the affected addresses.
    The tokens will be moved using the current exchange rate at the time of transfer if relevant.

We invite everyone to review and discuss this proposal both here and on our Snapshot Voting

Thank you for considering our proposal.

Best regards,
Younessnet

1 Like
2

Thanks @Younessnet for this.

I have a few questions:

  • The SQT token address is formally known as a burn address, do you propose that we change this as well?
  • How do you propose to verify accidental transactions?
  • What do you propose we do for anyone else that makes this mistake in the future? Should they also have the right to request a treasury payment for their mistake?

The tokens will be moved using the current exchange rate at the time of transfer if relevant.

  • What do you mean by this? In what case will we need to convert token values?
  • I’m interested if you can point to other examples where an ecosystem paid out treasury funds to people who accidentally sent their tokens to the burn address?
1 Like
3

Thank you, James, for your thoughtful questions. Here are the responses:

I made the mistake of sending my tokens to the token contract address due to a copy-paste error. After copying the contract address to add the token to my MetaMask wallet, I attempted to copy my other wallet address to send the tokens. However, the copy did not work as intended, and when I pasted, it was the contract address that got pasted instead. Consequently, I mistakenly sent my tokens to the SQT contract address.

Changing the Burn Address Designation

Question: The SQT token address is formally known as a burn address; do you propose that we change this as well?

Response: The current proposal does not include changing the designation of the SQT token burn address. However, it is worth considering as a future measure to prevent similar incidents. Changing the designation or implementing additional warnings or confirmations before tokens can be sent to the burn address could help mitigate accidental transactions. If there is community support, a separate proposal could address this potential change.

Verifying Accidental Transactions

Question: How do you propose to verify accidental transactions?

Response: To verify accidental transactions, the following steps are proposed:

  • Blockchain Analysis: Review the transaction history on the blockchain to confirm the tokens were sent to the SQT contact address.
    Here is the link to these transactions: Etherscan Transactions
  • User Submission: Require affected users to submit transaction details, such as transaction ID, date, and reason for the transfer. This information should be corroborated with blockchain data.

Handling Future Mistakes

Question: What do you propose we do for anyone else that makes this mistake in the future? Should they also have the right to request a treasury payment for their mistake?

Response: Establishing a clear policy for handling future mistakes is essential. Options include:

  • One-Time Exception: Treat this refund as a one-time exception, making it clear that future mistakes may not be eligible for refunds. This sets a precedent and discourages careless behavior.
  • Recurring Policy: Implement a structured process for future refund requests, including:
    • Defined Verification Procedures: Standardize the steps for verifying accidental transactions.
    • Cap on Refunds: Set a limit on the number of tokens or total value that can be refunded to prevent treasury depletion.
    • Review Period: Implement a review period to assess the impact on the treasury and ensure its health.
    • Community Vote: Require a community vote for each refund request to maintain transparency and collective decision-making.
      Clear communication to all token holders is necessary to set proper expectations and prevent misuse of the refund policy.

Exchange Rate Clarification

Question: The tokens will be moved using the current exchange rate at the time of transfer if relevant. What do you mean by this? In what case will we need to convert token values?

Response: The statement about using the current exchange rate implies that if there is a significant fluctuation in the token’s value between the time of the loss and the refund, the refund might consider this change. For instance, currently there is no significant difference between the token’s price at the time of loss and now, so the refund would be 1:1.

  • Significant Value Change: If the value of SQT tokens has significantly increased or decreased, the community might decide to adjust the refund amount to reflect the current value, ensuring fair compensation. This step would be necessary only if the token’s value changes considerably over time.

Examples of Similar Treasury Payouts

Question: Can you point to other examples where an ecosystem paid out treasury funds to people who accidentally sent their tokens to the burn address?

Response: Here are a few examples:

  • MakerDAO (DAI): There have been instances where users accidentally sent DAI to incorrect addresses, and the community voted to refund these users after verification.
  • Ethereum Classic (ETC): The Ethereum Classic community has discussed and occasionally refunded users who sent ETC to wrong addresses, following thorough verification and community voting.

These examples highlight the importance of community approval and thorough verification processes to maintain transparency and trust within the ecosystem.

1 Like
4

Can you please provide sources for your references to MakerDAO and Ethereum Classic. For example:

In addition

  • As you describe, you will carry out verification of accidental transactions. Are you planning to carry this out before submitting the concrete proposal for treasury spend?
  • A final STP will require an exact amount of SQT described with relevant payout addresses, can you please provide this information. Perhaps a table with the columns SQT amount, and Destination wallet is a good way to formalise this? Otherwise this proposal lacks necessary implementation details.
1 Like
5

Hi James,

Thank you for your follow-up questions. Here are the detailed responses:

Sources for MakerDAO and Ethereum Classic References

MakerDAO Example:
The reference to MakerDAO involves a proposal where the community voted against refunding users who lost money by sending Dai to the Dai contract address. You can find the details of this proposal here:
Maker Governance - Ratification Poll - Declaration of Intent - Implement a Feature to Refund People who Lost Money Sending Dai to the Dai Contract Address (MIP13c3-SP14) - February 13, 2023.

Ethereum Classic Example:
Regarding Ethereum Classic, it is well-documented that the network maintains the original, unaltered history of the Ethereum network following the DAO hack. This stance underscores the importance of immutability within their community. More information can be found on their Wikipedia page:
Ethereum Classic - Wikipedia.

dYdX Example: Additionally, the dYdX community has also addressed similar issues. They proposed a payback from the community treasury for users who locked tokens on the dYdX contract address. Details of this proposal can be found here: dYdX Community Discussion - Payback from Community Treasury for People Who Locked Tokens on dYdX Contract Address.

Verification of Accidental Transactions

Question: As you describe, you will carry out verification of accidental transactions. Are you planning to carry this out before submitting the concrete proposal for treasury spend?

Response: Yes, the verification of accidental transactions will be conducted before submitting the concrete proposal for treasury spend. This ensures that all the details included in the proposal are accurate and verified, providing the community with confidence in the legitimacy of the claims.

Detailed Implementation of the Final STP

Question: A final STP will require an exact amount of SQT described with relevant payout addresses. Can you please provide this information? Perhaps a table with the columns SQT amount and Destination wallet is a good way to formalize this? Otherwise, this proposal lacks necessary implementation details.

Response: Below is the detailed table with the verified accidental transactions, including the amount of SQT and the destination wallet addresses:

SQT Amount Destination Wallet Address
161,583 0xbf8627F3849d60421D0F5978Fc7685e561f7F8c0
250,000 0x750Ea760b19f87DdE87492b69479a5b0a094B018
58,333 0xBCCE1B14167bA143608878A82FC1DAFA060DDCEE
80,000 0xF908Afe5EF8957370368F92F79ac6Ea02ad490e7
65,833 0x0B9C6B10F3C4aC52c52E40299d94F5206D79968A
31,484 0x4a06dB7e6623ebA323545D7329B2A29b676f7A33
246,666 0xC69c6807C3d8a8696f13ec15656631e2Bf2bF6A3

Total: 893,899 SQT

Additional Context on Recovery Mechanisms

It is important to note that some tokens have built-in recovery mechanisms for situations like this.
For example, projects utilizing the Eth Token Recover tool can recover tokens accidentally sent to the contract address.
Unfortunately, since SQT does not have this implemented and is not upgradable, we rely on our community treasury to help those who lost their tokens due to this small mistake.

More information on Eth Token Recover can be found here: Eth Token Recover.

Thank you for your thorough review and support in ensuring the transparency and accuracy of this proposal.

1 Like
6

Two quotes from you:

“However, the treasure wallet was established to address a variety of unforeseen events, including user errors like sending tokens to the wrong address.”

and

“I made the mistake of sending my tokens to the token contract address due to a copy-paste error./Consequently, I mistakenly sent my tokens to the SQT contract address.”

I understand how frustrating it can be to lose funds due to your own mistake. I don’t fully understand why you call it an unforeseen event. This seems to remove responsibility from the user for his actions. A protocol hack or an error in a smart contract is a situation that affects everyone. And this is truly an unforeseen event. Sending tokens to the wrong address is not an unforeseen event. This is a foreseen circumstance, a risk that every cryptocurrency user bears every day.

Quote:

“If the value of SQT tokens has significantly increased or decreased, the community might decide to adjust the refund amount to reflect the current value, ensuring fair compensation.”

You need clearly understand that when you send your funds to some incorrect address and then ask the community to return the money to you from the Treasury, this is not compensation. Compensation is when something happened through no fault of yours. Incorrect address in the input field is your full responsibility. It’s not the community or team’s fault that you did this, so it’s not compensation. You are actually asking for a gift.

Converting the size of a gift depending on the price movement in the market is something beyond my understanding.

Are you really considering the scenario where if a user sends tokens to the contract address and the price drops during this time, the community should allocate more tokens than the user lost?

Quote:

“Treat this refund as a one-time exception, making it clear that future mistakes may not be eligible for refunds.”

Then you need to provide convincing arguments about how your case differs from all similar ones in the future. Because the rule should work the same for everyone, without making exceptions.

8

Hi nextOne,

Thank you for your detailed feedback and questions. I appreciate the opportunity to address these points more precisely and clearly.

**Response to “Unforeseen Event” **
You are correct that sending tokens to the contract address SQT is a user error and not an unforeseen event in the traditional sense, such as a protocol hack.
My use of the term “unforeseen event” was meant to cover a wide range of scenarios, including significant user errors.
I fully acknowledge that this was the mistake of seven people, and we take full responsibility for it.
The intention behind the proposal is to seek a one-time goodwill gesture from the community, not to absolve us of responsibility.

Response to “Gift vs. Compensation”:
You are right; this request is more accurately described as asking for a gift from the community, rather than compensation.
Compensation implies an obligation on the part of the community, which is not the case here. We are asking the community for a one-time act of goodwill to help rectify our mistake.
Therefore, it is the community that decides what happens next through the establishment of a vote where each member can freely express their choice.

Clarification on Market Value Adjustment:
I understand your concern about adjusting the refund amount based on market value changes.
The reference to adjusting the refund amount based on market value was to ensure fairness in case of significant token value fluctuations, which is a mandatory element featured in the STP documentation.
To comply with this requirement, we must include this consideration, even if it complicates the process.
However, for simplicity and fairness, I propose maintaining a 1:1 refund ratio, regardless of market fluctuations, unless the community decides otherwise.

Response to “One-Time Exception”:
To ensure fairness and prevent setting a precedent for future similar requests, this proposal should be framed with clear and specific boundaries. Here are the key points:

  • Unique Circumstances:
    This proposal is presented as a one-time exception due to the specific nature of the error and its impact.
    It does not set a precedent for future cases.
  • Policy Development:
    I suggest developing a clear policy for handling future similar requests to ensure transparency and consistency.

Raising Awareness and Prevention

I think that this subject can help the members of the community avoid making the same mistake as the seven people involved.
By highlighting this issue, community members will be more attentive to such errors.
Additionally, this can help other projects to set up a system for recovering tokens sent to the contract address before the launch of their future projects.

1 Like
9

How about a 50% refund to acknowledge both goodwill from the community as well as a cost for the mistake.

10

However, on DYDX, the community granted a 90% refund with a 10% penalty for errors.
Ultimately, it is the community that will decide on the final terms.

11

Hi everyone,

We are excited to announce that our first treasury proposal is now live!
This proposal requests that the council send 893,901 SQT from the SubQuery Treasury to several addresses that mistakenly sent tokens to the SQT contract address.

We kindly ask you to review the proposal and cast your vote at your earliest convenience.
Your participation is crucial in ensuring the proper allocation of our treasury funds.

Please review and cast your vote here: Snapshot Voting

Thank you for your attention and support.

12

I’m in agreement with @nextOne. There should not be a precedent set that this is a favor from the foundation to refund someone one time because they screwed up, but then say “let’s make this a learning lesson for future people and not refund them”. That makes no sense. Unless it’s a protocol issue, then there should be no refund, no matter the amount of tokens and value.

13

I understand that we may not share the same point of view, and that’s precisely why we have set up a community vote.
This democratic process is fundamental to our project’s governance, allowing all voices to be heard and considered.
By putting this decision to a community vote, we ensure that the final outcome reflects the collective will of the community, rather than the opinion of a few individuals.

This approach fosters transparency and inclusiveness, ensuring that every member has the opportunity to participate in the decision-making process.
It also helps us gauge the overall sentiment of the community on this issue, providing a clearer understanding of the majority’s perspective.

Ultimately, the community has the last word on this matter.
This ensures that any action we take is backed by the consensus of the community, which is essential for maintaining trust and integrity within our ecosystem. Thank you for engaging in this important discussion and for contributing your views.

1 Like
14

If I follow this proposal, can I also request a refund of the money that was appropriated by the hacker?

15

As per the result of the vote of STP-1, the impacted users have been paid tokens from the SubQuery treasury Base Transaction Hash (Txhash) Details | BaseScan

3 Likes
16

Dear SubQuery Community and SubQuery Team,

I am writing to express my heartfelt gratitude for your swift action in refunding the tokens that were mistakenly sent to the SQT Ethereum contract address.
Your prompt response and dedication to the community’s well-being are truly commendable.

This refund would not have been possible without the collaborative efforts of the community members and the diligence of the SubQuery team.
Your support has reinforced my confidence in the integrity and reliability of the SubQuery network.

Thank you once again for your assistance and for demonstrating such a strong commitment to your users.

Warm regards,
Younessnet