Settlement & Claims
At scale, iterating every address's fill and refund in a single on-chain transaction is gas-infeasible — and it reintroduces exactly the ordering-dependence the auction was designed to avoid, since someone has to be first in the loop.
Jump instead computes settlement off-chain over the frozen deposit set and commits only a single Merkle root on-chain.
Fig. 06 · Settlement is computed over the frozen set and committed as one root. Everything a participant does afterwards is a pull against that commitment.
Leaf Construction
The BSC migration specification uses the following seven-tuple; final ABI field names must match the released implementation:
( chainId, projectId, roundId, snapshotVersion,
account, tokenAmount, refundBnbAmount )
chainId = 56 for BSC mainnet. refundBnbAmount is an integer number of wei, with 18 decimals per BNB. WBNB delivery or native BNB unwrapping must preserve this same quantity, with independent claim flags for the token and refund rights.
| Field | Why it is in the leaf |
|---|---|
chainId, roundId |
Prevents cross-chain and cross-round replay of a valid proof. |
snapshotVersion |
Makes a corrected root a distinct, non-ambiguous commitment rather than a silent overwrite. |
tokenAmount, refundBnbAmount |
Both outcomes are committed together, so a participant's full settlement is verifiable from one leaf. |
Immutability and Correction
Once a root is activated it cannot be silently replaced.
If an error is discovered after publication, the only remedy is to pause the round and publish a new root under an incremented snapshotVersion. There is no code path that mutates an already-active root in place.
A correction is therefore always a new, externally visible commitment — never an edit. Anyone tracking the round sees that a second version exists and can diff it against the first.
Claim Semantics
Token allocation and BNB refund are treated as independent claim rights from the same committed leaf.
- Claim them together or separately, in any order.
- A user who has not claimed one is never blocked from claiming the other.
- No claim of one can invalidate the other.
All claims are pull-based. The contract exposes a claim function that the user calls with a Merkle proof, guarded by checks-effects-interactions ordering and re-entrancy protection.
Why pull, not push
Pushing refunds in bulk bounds the protocol to whatever the most expensive recipient costs. One malicious or non-standard address that reverts on receipt would block settlement for everyone behind it in the loop. Pull-based claiming caps gas per transaction and makes every participant's settlement independent of every other's.
What Fails, Deterministically
All of the following are rejected without ambiguity: a tampered proof, a proof against a stale root, a replayed claim, and a re-entrant claim call. See Invariants.