Bug: Fuzz test failure — max spread assertion off by rounding at extreme pool imbalance #53
Labels
No labels
agent:fix_bugfix
agent:fix_conflicts
agent:fix_security
agent:gap_analysis
agent:implement
agent:implement
agent:implement
agent:open_issues
agent:ready
agent:research
agent:security_audit
agent:verify
architecture
backend
blocker:hybrid
blocker:launch
blocker:limit-orders
blocker:v2
block:log_only
block:security
bug
ci
contracts
correctness
deploy
dev
devops
docs
documentation
duplicate
e2e
enhancement
epic
feature
frontend
functional-completion
gas
good first issue
governance
help wanted
high-risk
hooks
hybrid
indexer
infra
infrastructure
integrators
invalid
launch-blocker
limit-orders
localnet
localterra
low priority
missing-implementation
needs-design
ops
performance
priority
high
priority
medium
product
qa
QA
question
ready
ready
research
scripts
security
security-hardening
smartcontracts
tech-debt
testing
ux
UX
v2
verification
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
code/cl8y-dex-terraclassic#53
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Current behavior: fuzz test prop_interleaved_provide_swap_withdraw fails. actual spread (1.000012258707768751) exceeds max allowed (1.0). minimal failing input: init_a=869183, init_b=100000, add_a=10000, add_b=10000, swap_amount=99710. the spread check rejects a swap that exceeds max_spread=1.0 by 0.001% due to precision rounding at extreme reserve ratios.
Expected behavior: spread assertion should account for rounding precision at extreme ratios, or the spread calculation should handle this edge case gracefully. a swap at max_spread=1.0 (100% tolerance) should not fail due to sub-basis-point rounding error.
Acceptance criteria:
commit
671e72f.mentioned in issue #50
mentioned in commit
9152da1bb7Pushed a fix in
9152da1onmain.Cause: With
belief_price: None, spread isfloor(offer × out / in) − grosswhilegrosscomes from the CP path withceil_div. At very skewed reserves that integer mismatch can make rawspread_amountlarger thanreturn + commission, soDecimal::from_ratio(spread, total_return)goes slightly over1.0even when the user asked for 100% tolerance.Fix:
assert_max_spreadnow comparesmin(spread_amount, total_return)tomax_spreadonly for this check (attributes/hooks still emit the raw spread). Shared helperspot_linear_spread_over_grossis used for swap execution,Simulation, andReverseSimulation. Unit tests added on the pair crate;prop_interleaved_provide_swap_withdrawruns 256 cases; all 286 contract tests pass.@brouie can you confirm this matches what you saw on the fuzz failure? Leaving the issue open until verified.
Verified on
38afbf8. New spot_linear_spread_over_gross helper caps spread at total_return so the ratio never exceeds 1.0 at extreme pool imbalance. Contracts 286/286 (was 285/286). Fuzz test that was failing now passes.