One Shot: Reloaded

First Flight #47
Beginner FriendlyNFT
100 EXP
View results
Submission Details
Impact: low
Likelihood: medium
Invalid

Unstaking requires the module owner signature, adding centralization to the staking process.

Root + Impact

Description

Staking and unstaking in a decentralized application should happen at the will of the token owner. When they stake their rapper, the NFT owner does it by himself. But when they want to unstake, they also need the signature of the module owner for the transaction to occur.

This adds centralization to the protocol, and allow the module owner to control when a staked NFT can be unstaked

// In streets.move
// ↓↓↓↓↓↓↓ ↓↓↓↓↓↓↓
public entry fun unstake(staker: &signer, module_owner: &signer, rapper_token: Object<Token>) acquires StakeInfo {

In Aptos move, the type signer can only be generated by signing a transaction, so users need to wait the owner to sign before having their NFT unstaked.

Note: Compared to the usual rule where "owner is trusted", this issue suggests that the owner may take time to accept the transaction. Because there is an easy alternative to this behaviour, I believe this is a valid issue.

Risk

Likelihood:

This will happen every time a user wants to unstake.

Impact:

At least delay the user from having their tokens unstaked. At worst not being able to call unstake

Recommended Mitigation

The module owner should not be signing the transaction. It is currently used for minting cred tokens, and for receiving/transfering the NFT object for staking.

cred_token minting can simply be updated by removing the module_owner from the parameters. The cap is to be stored in the init function.

For the object transfer, a deeper refactoring needs to occur, as the SignerCapability has to be saved in the init function for future transfer without requiring having module_owner as a signer for the transaction. For more details regarding how to implement it, you can take example from the aptos-move staking example

Updates

Lead Judging Commences

bube Lead Judge 18 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Appeal created

strapontin Submitter
18 days ago
bube Lead Judge
17 days ago
strapontin Submitter
17 days ago
bube Lead Judge
16 days ago
bube Lead Judge 16 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.