Background:
As many are aware, slope leaked an unknown amount of seed phrases (and hence an unknown amount of wallet addresses!).
In their initial attack, c. 9.2 wallet addresses had funds drained (Dune), though attackers largely focused on liquid SOL / USDC / large cap positions.
Currently, funds are not being sniped from wallets. There is no sign that attackers are executing smart contracts either.
As Toly wrote: It is only a matter of time once attacker will resume the attack (https://twitter.com/aeyakovenko/status/1554971311960510464). For anyone with locked staking positions, the 28d window to unstake might not be sufficiently long enough. Once these token become liquid, there is a high likelihood they will be drained.
Proposed Solution:
In order to safeguard those user’s funds, I’d suggest to implement an emergency procedure to move locked JET in a new wallet. I’ll leave it up to the devs on how to best implement it; a pragmatic solution (signing a trx to re-delegate the authority to another wallet?) would be ideal.
Needless to say, such a function could also be called by a hacker, yet as there is no evidence this is happening (and I doubt JET DAO would be an initial target, given it’s relative low amount of TVL) yet.
–
Again, time is of essence here - inaction will lead to users leading funds. The protocol DAO & development team has the duty of care to protect users funds. I’ll trust they will honour this duty in the best possible manner
Hmmm. We should consider how we might help, but protocols are not intended to be safe against users losing control of their private keys.
@adamdelsol@jrmoreau Perhaps some messaging to affected users with staked JET is in order? As long as users check their stake every 28 days and cancel unbonding they did not initiate, the JET cannot be withdrawn.
@tmnxeq the problem with your suggestion in its bare form is that attackers could perform the re-delegate action themselves. Perhaps you’ve thought about how to work around that?
I kind of wish we’d stored phone numbers during governance authentication, so we could use an OTP procedure to identify legitimate instructions from the original stakers. As things stand, I don’t think we have a good idea about how to safely move staked JET from control of compromised wallets.
@tmnxeq what have you seen other protocols doing about this?
For anyone with the technical capability: how much overlap is there between the obviously compromised wallets listed here, and owners of stake in Jet Protocol?
A lot of the effort did seem to be surprisingly manual and brute forced however.
Evidence rn shows they are currently not even sniping liquid tokens. The attack vector you cite currently doesn’t exist
I heard a wide range of reactions, from apathy, aggressiveness (“what if you are the scammer”, “it’s your fault”), proactive outreach & pragmatic solutions. A litmus test of a project’s culture.
I’d like to highlight the latter as it really shows how much protocols care about users.
Please no, the answer to this can’t be more private data being stored by a third party. (Even asking for phone verification…don’t get me started). It’s enough that the redacted slope people transfered unencrypted seed phrases to their centralized server…
As explained earlier, I don’t think an additional verification step is necessary.
@tmnxeq there’s no straight forward way to address this technically - that needs to be understood. Regardless of whether it’s more KYC or not, it shouldn’t matter because in-fact if the hacker has your private keys they’ll be able to move your funds as fast as you can if not faster.
But take for instance if a user didn’t want to KYC for such a rescue plan, how does one distinguish between the victim and the hacker? Who’s to be trusted?
Regardless of whether there’s a path forward on this, I’d suggest any user that seeing their JET tokens being un-staked that did not initiate this simply cancel the un-staking process. This can be done continuously - give you the ability to more or less keep the funds from moving at least.
How many others have experienced this? I’d love to see some idea of the number of people affected on Jet Protocol.
Regardless of whether there’s a path forward on this, I’d suggest any user that seeing their JET tokens being un-staked that did not initiate this simply cancel the un-staking process. This can be done continuously - give you the ability to more or less keep the funds from moving at least.
Affected users have over 4 weeks to respond to an un-stake initiation performed by the attacker. If you’ve experienced this on the protocol, please re-stake immediately, and post in this thread details about your situation. Then we can begin crafting a governance response ensuring there’s no adverse actions.
For any affected Jet users there is still plenty of time remaining to respond to the situation.
Any solution must go through the governance process. The idea of creating a solution that allows for easy transfer of account ownership also makes it just as easy for the attacker to transfer ownership away from the original account owner.
Jet is a DeFi protocol, and as such, protocol devs can’t just act unilaterally and make ad hoc arbitrary decisions on behalf of users.
As always we encourage protocol users to use hardware wallets, especially when managing large amounts of digital assets. Hot wallets are at greater risk of being compromised.
Again a hypothetical, current thread model was explained by me in the above post
Did anyone read the posts?
FWIW, I obviously initiated the unstake of remaining tokens. After all the play is to move tokens (either as locked positions or liquid) before keys get in the hand of more sophisticated players
