In the case of your proposal, I will not set a deadline for the swap from ASTR/USDC to DOT and for the distribution. The reason for this is already written in the proposal. Moreover, even if there were no deadline, the community is unlikely to choose that option. As I’ve said repeatedly, Acala’s users are not the only users of Starlay, and the primary priority is the growth of Starlay.
Also, I don’t believe I need to add your calculation to the proposal. It’s already understandable. But I just confirm that your formula is correct and will use the formula.
If we were to add your option as a DOT-based option (excluding the swap, same as options 1-2), option 1-1 would be changed to return DOT based on a USDC value in the event of a DOT return. Including your option for discussion, and revisiting the discussion for option 1-1 when DOT is returned, would lead to further delays.
The following example illustrates, “why is it critical to use current DOT value during compensation and not to use DOT value during hack while calculating %compensation”
Note: The following numbers are used only for illustration and not to consider literally
Example: User A lost 1000DOT during STARLAY hack and sometime in the future STARLAY recovers all the hacked DOT.
Number of DOT user lost(nDOT) = 1000DOT
DOT price during hack(D1): $8
Value of lost DOT in USD (vDOT) = nDOT x D1 = 8000USD
PS: The above example illustrates why using current DOT value during initial compensation for calculating %compensation is crucial for users to incur no loss and how it is also advantageous for STARLAY if the hacked DOT can be recovered.
Did you read my replies? You are just presenting your own argument without reading my replies at all. Moreover, your calculation formula only contains arbitrary elements and does not take into consideration the possibility of DOT’s price dropping.
To reiterate, if we calculate based on the DOT value base you mentioned, 1. I will not set a deadline for the swap from ASTR/USDC to DOT and for the distribution, 2. Option 1-1 would be changed to return DOT based on a USDC value in the event of a DOT return, 3. revisiting the discussion for option 1-1 when DOT is returned and adding your option would lead to further delays.
Please take a moment to review all our discussion so far, our previous correspondence, the current status of Starlay’s Treasury, and the dApp staking. After reviewing these, join the discussion.
Hello, yes I have read the proposals so far and am actively following it. But I feel you haven’t gone through the example which clearly explains what would happen if SCI waits for DOT price to drop(Scenario 3) for compensation. One thing to keep in mind is, if the hacked fund is recovered in the future it will be in DOT and we do not have control over it. So I the capital lost and which might be recovered in the future is in DOT, why should USD/ASTAR be used as frame of reference. Again I am not requesting to change ASTAR to DOT, we the users will do it ourself (taking hit on slippage/trading fee). And also there will be no change in capital compensated because of this request, 50% Treasure is there to stay with SCI for operations and growth. The request is to use the right frame of reference to calculate the %compensation. If not the 25% increase in DOT price from the time of Hack to issuance date is going into the pocket of SCI.
If a DEFI protocol has a disclaimer, “The protocol can be compromised/hack at any time, please invest at your own risk”. No one will be joining the protocol. As a user of a protocol, losing capital because of market bets is fine because it is the user who is taking their own risk. But if the DEFI capital is compromised, it is like DEFI protocol taking risk at users expense.
It is already understandable for you but not for me. If you have a definite equation/numbers to back up the statement, I wouldn’t be questioning what the word AMOUNT means. It is highly open for interpretation and can be claim to be anything in the future.
You’re really not seeing the whole picture. First, repeatedly said though, Acala’s users are not all the users. If we consider the protocol, option 1-1 would likely be chosen. Currently even in the case of option 1-1, we have specified, “※ If the DOT is returned, it will be returned as a percentage of the amount at the time of the hack, not by its USD value.” However, if your option were to be included, in the case of option 1-1, it would result in a return based on USD value. As I’ve said repeatedly, Acala users are not all the users. Option 1-1 is likely to be chosen. You would understand what kind of calculation would be made if there were a return of DOT in that scenario. This proposal should come across as the shortest and prioritizes the protocol while also being favorable for Acala users. I hope you understand now
Though Acala users are not the only user, they do make up a significant % of the userbase of Starlay. I still do not agree with what you are proposing. But as you point out, the current focus is to get the protocol back up and running. May be this topic regarding %compensation can be discussed and come to a consensus in the future. Thank you.
1. Identify Impacted Addresses:
You have already tracked the addresses affected by the hack. By doing so, you know precisely who suffered losses during the security breach.
2. Partial Refund in ASTR:
I propose refunding the tokens in ASTR (regardless of the specific amount). Let’s allocate 45% of the original amount as an immediate refund. However, it’s important to note that the remaining 55% still requires compensation.
3. Recovering the Remaining 55%:
To recover the outstanding 55% funds, consider the following approach:
Encourage affected users to stake $ASTR with Starlay.
Provide these users with earnings from their specific stakers as monthly airdrops. Crucially, refrain from retaining any earnings that Starlay receives from stakers who suffered losses during the hack.
Repeat this process until the full 55% is compensated or until Astar continues to provide rewards.
I believe this strategy strikes a fair balance between addressing the losses and ensuring ongoing rewards for affected users. How?
The affected users can take the ASTR and do anything they want, Starlay will not get any benefit from it and the affected users will not be able to get any compensation.
However, the affected users stake 1000 ASTR with Starlay. Starlay gets a commission/rewards/incentive from ASTR. Starlay gives it back to the same user without retaining them.
This airdrop/refund of fees will not be applicable to the non-affected users, so, some manual intervention will be needed. Starlay doesn’t loose anything, however, the affected users get something back each month.
