Repository navigation
fix(web): receiver snippet arms each loan (vetting C7) and reads the fee - #136
Open
emmanuelist wants to merge 1 commit into
Open
emmanuelist wants to merge 1 commit into
emmanuelist wants to merge 1 commit into
Conversation
Follow-up to mattglory#127, per review: anyone can call flash-loan naming a receiver, so a receiver built from the mattglory#127 snippet could be made to run its strategy and spend its fee buffer by a stranger. The snippet now follows docs/security/RECEIVER_VETTING.md the way hk-sbtc-real-receiver-v2 does: - C7: the owner arms exactly one loan amount (arm-loan / disarm, both owner-only, nonzero). The callback requires an exact match and clears the arm before the strategy runs, so an unarmed loan reverts (u402). - B4: the contract-caller gate runs before any state is read. - D12: fee from the core's get-fee-basis-points with max(1, floor), instead of a hardcoded 5 bp. - Points to E17/E18 (owner-only rescue, two-step ownership) and C9 (measure profit against the starting balance). - Labelled Clarity 3: the live core requires epoch 3.4, and Clarity 4 replaces as-contract, so the snippet as written compiles only as Clarity 3 at epoch 3.4. Verified on the exact text shown on each page: clarinet check against the real mainnet trait and core, and 9 simnet tests through the real core at its mainnet address (stranger reverts, arm single-use and bound to amount, fee follows the core). Removing the arm check fails 5 of 9.
|
@emmanuelist is attempting to deploy a commit to the matt glory's projects Team on Vercel. A member of the Team first needs to authorize it. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Follow-up to #127, as you asked. Anyone can call
flash-loannaming a receiver, so a receiver copied from the #127 snippet could be made to run its strategy and spend its fee buffer by a stranger. The snippet now followsdocs/security/RECEIVER_VETTING.mdthe wayhk-sbtc-real-receiver-v2does:arm-loan (amount)anddisarmare owner-only (and reject zero). The callback requires(is-eq (var-get armed) (some amount))and clears the arm before the strategy runs. An unarmed loan reverts withu402.contract-callergate first, before any state is read; repays the hardcoded core.get-fee-basis-pointswithmax(1, floor(...)), instead of the hardcoded 5 bp in #127./receiversintro text now says why the arm matters and links the vetting checklist. The landing paragraph no longer says "implement one function".Clarity version: the snippet is labelled Clarity 3. The live
flashstack-stx-corerequires epoch 3.4, and Clarity 4 replacesas-contract, so this exact code compiles only as Clarity 3 at epoch 3.4 (checked both; Clarity 4 fails with "unresolved function as-contract"). #127's check used Clarity 2 / epoch 2.5 with a local copy of the trait. That was fine for #127 because its snippet never called the core, but this one does, so this time I checked against the real mainnet contracts.Type of Change
Related Issues
Follow-up to #127. Related to #111.
Testing Performed
All on the exact text shown on each page (extracted from the source; the
/receiverscopy is byte-for-byte the landing one plus its "deploy" note):clarinet check, Clarity 3 / epoch 3.4, with the realSP3TGRVG….stx-flash-receiver-traitandSP20XD46….flashstack-stx-corepulled in as[[project.requirements]]: ✔.contract-callermatchesFLASH-COREand the fullflash-loanpath runs. That's the pathbitflow-arb-receiver-v5-security.test.tsnotes it can't reach with the local core copy.execute-stx-flashcall →u401flash-loan, nothing armed →u402, no balance movesu403,u400)set-fee-basis-points(20 bp test)tsc --noEmitpasses. No new lint problems (the 2 inpage.tsxwere already onmain).<pre>blocks whose overflow behaviour was checked at 390/1440 in fix(web): teach the hardened receiver pattern, not the F-10 one #127.Clarinet.toml and test file (vitest 4.1, clarinet-sdk 3.25), if Hillary wants to rerun
contracts/armed-receiver.claris the landing snippet verbatim.Happy to add this test to
tests/if you want it in CI. It needs the snippet as a contract entry inClarinet.toml, which I didn't want to add to the deployment config without asking.Additional Context: the 5,000 vs 500,000 cap
While reading the core for this, I think I found where the 5,000 STX number comes from.
flashstack-stx-core.clarhas:u500000000000µSTX is 500,000 STX, so the comment is off by 100×, and the form'sMAX_LOAN_STX = 5000(with its own contradictory comment) looks copied from it. Which value is intended is still your call; I only fixed text here.Deployment Considerations
No contract changes.
By submitting this PR, I confirm that: