Vitalik Buterin on Warpcast

Content pfp

0 reply

0 recast

0 reaction

Vitalik Buterin pfp

Vitalik Buterin

The contract here is a sublinear staking contract: if you are in the whitelist (specified as an ERC1155 collection), then you can stake N coins, and get a return of N ** 0.75 coins per slot, for as long as the contract has coins to pay for it. There is a fundedUntil mechanism that ensures that if the contract runs out of money, every staker gets rewarded for every slot up to the fundedUntil timestamp, and the mechanism doesn't turn into a fractional reserve. https://github.com/ethereum/research/blob/master/sublinear_staking/code.vy Bounty of total 2 ETH for identifying any bugs / vulnerabilities in the contract and proposing specific fixes, if multiple issues are found the bounty will be split based on severity. Amount: 2 ETH @bountybot

23 replies

174 recasts

763 reactions

Bounty Bot pfp

Does this bounty require an application process? i.e. interested users should confirm with you first before working on it This helps avoid potential duplicate work on some bounties if not specified

0 reply

3 recasts

4 reactions

Bounty Bot pfp

Confirmed! On your bounty page, you can pay users and view their bounty completion history Frame buttons - Admin: manage bounty status (in progress, complete), amount, deadline, add boost to get more attention on your bounty 🤖 commands - @bountybot cancel - @bountybot in progress - @bountybot complete (optional: tag winners) - @bountybot shoutout (optional: tag winner and write a positive review)

0 reply

0 recast

2 reactions

borodutch pfp

@warpcastadmin.eth

i wonder if line 88 should go before line 83 🤔 still exploring and trying to make sense of liabilities, just a hunch

1 reply

0 recast

5 reactions

androolloyd.eth |⬛️|🦇🔊 pfp

androolloyd.eth |⬛️|🦇🔊

@androolloyd.eth

something worth noting the isEligible check only happens on staking, so a user can acquire inline a token to flag true without having to actually hold the token for the duration of the staking. You'd likely want to do something where the eligible tokenID is locked into the staking contract for the duration.

1 reply

0 recast

1 reaction

Francesco Piccoli pfp

Francesco Piccoli

Not a critical vulnerability but considered a minor issue that can lead to inefficiencies and potential edge case behaviors: - The `stake` function does not verify that the `amount` to stake is greater than zero. Allowing users to stake zero tokens can lead to unnecessary state changes and potential edge case behaviors. - Recommendation: Add a require statement in the `stake` function to ensure that the `amount` is greater than zero before proceeding with the staking logic.

1 reply

0 recast

4 reactions

✳️ dcposch on daimo pfp

✳️ dcposch on daimo

not a vulnerability, but you probably want a configurable multiplier on getReturnPerSlot, otherwise results depend on token decimals. for example, stake 1 USDC = 1e6 ^ (3/4) = $0.03 reward per slot stake 1 DAI = 1e18 ^ (3/4) = $0.00003 reward per slot

0 reply

0 recast

29 reactions

Varun Srinivasan pfp

Varun Srinivasan

0 reply

0 recast

7 reactions

dark horsefacts pfp

dark horsefacts

@horsefacts.eth

0 reply

0 recast

2 reactions

Francesco Piccoli pfp

Francesco Piccoli

Nice, we’ll run some scans with @almanax

0 reply

0 recast

1 reaction

Dennison Bertram pfp

Dennison Bertram

This is pretty incredible to see! Have you seen our Governance Staking Contracts? To use staking to drive participation in governance? https://github.com/withtally/govstaking

0 reply

0 recast

0 reaction

🦒 pfp

0 reply

0 recast

0 reaction

borodutch pfp

@warpcastadmin.eth

here's one issue: technically if someone stakes enough, they can bring `_fundedUntil` down so much that no one will get any rewards, but the entity that stakes enough token will get all the rewards moreover, the `isEligible` check just checks the balance of the token, which means if the token supports flash loans, one can flash loan large amount of token to stake, `stake`, bring down `_fundedUntil` to (maybe?) the same block, `unstake`, sell the rewarded token, cover cost of the flash loan and get profit can probably be mitigated by having a time-lock mechanism for staking (this should eliminate the threat of flash loans); maybe also limiting amount of rewards per address (but then one can spawn many addresses); or maybe limit the rewards by the proportion of total supply of the token staked? not sure

1 reply

1 recast

26 reactions

Catch0x22 pfp

@askgina.eth can you explain what this contract is for in simple terms

1 reply

0 recast

1 reaction

sarvad.base.eth pfp

sarvad.base.eth

@sarvadshetty.eth

ive never relly looked into to vyper but in the _unstake function shouldnt there be a require like check if the total amount to be sent back to the user is available in the contract?

0 reply

0 recast

0 reaction

sebayaki.eth pfp

looks good overall, but I found a few potential issues: 1. ```vy def _fundedUntil() -> uint256: return ( self.liabilitiesLastUpdated + (staticcall STAKED_TOKEN_ADDRESS.balanceOf(self) - self.liabilities) // max(self.totalPayoutPerSlot, 1) ``` If the contract’s balance of the staked token `balanceOf(self)` is less than the total liabilities `self.liabilities`, the subtraction will underflow, causing a revert on `_unstake` method. It might be okay, but it would be better to handle it properly. 2. ```vy def stake(amount: uint256): ``` A user can stake an amount of 0, which could cause potential issues in other parts. I think adding an assertion `assert amount > 0` if staking a zero amount is not intended.

0 reply

0 recast

0 reaction

Codingsh pfp

0 reply

0 recast

0 reaction

ruz.eth 🍄 pfp

Ser. Can you make the contract hold an LP position, and pay out the LP yield? In this way, you have a lower initial payout but it could continue indefinitely.

0 reply

0 recast

0 reaction

borodutch pfp

@warpcastadmin.eth

so, `_fundedUntil` is only relevant on L79 and is only used if it's in the past, it is whatever amount of token is free (balance - liabilities) divided by the current rate of paying out tokens per second + after the last time liabilities were recalculated `correctedNow` from L80 is probably more like `currentEndOfPayouts` time so the `liabilitiesLastUpdated` will turn into whatever `_fundedUntil()` was last when `_fundedUntil()` was in the past unless the contract is funded with more tokens and `_fundedUntil()` suddenly jumps into the future (or later than the locked `_fundedUntil()`)? not sure if there's an unintended behavior here (e.g. someone getting "short-sided" with less tokens than they would have gotten if they unstaked after the topup?) wonder if there's a vector of attack to fund the contract with more staked tokens directly (bypassing the `stake` function)? mitigation would be to lock `_fundedUntil()` if it ever gets behind `block.timestamp` 🤔 still exploring

1 reply

0 recast

0 reaction

MM pfp

Can you follow @kevinmfer so he hopefully comes back to us? Thanks for everything btw

0 reply

0 recast

0 reaction