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
Each leaf commits to a seven-tuple:
( chainId, projectId, roundId, snapshotVersion,
account, tokenAmount, refundUsdgAmount )
| 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, refundUsdgAmount |
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 USDG refund are treated as independent leaves of the same commitment.
- 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.