For Participants
1. The Window Opens
Every project's auction runs for a fixed window. While it is open, the contract accepts deposits and nothing else — no allocations are computed, no price is published, and no participant can see or influence where the round will land relative to anyone else's position in a block.
You may deposit ETH, USDG, or Stock Tokens. Non-USDG deposits are routed through a controlled swap at the moment of deposit, and the amount credited to you is the USDG actually received — not a quote, not an expected amount.
If the conversion fails
If that conversion fails, the deposit simply does not enter the auction. A failed conversion is never credited to your deposit balance — this is a release-blocking invariant, not best-effort behaviour. See Invariants.
Multiple deposits from the same address are aggregated into a single deposit balance z_i before any other computation runs. Depositing five times is identical to depositing once.
2. The Window Closes
At the close, the contract freezes inputs and runs a single test. Either the round clears, or it fails — there is no third outcome and no intermediate state.
| Outcome | What happens to you |
|---|---|
| Clears | Your effective contribution and token allocation are computed, a Merkle root is published, and the Canonical LP is created. Any part of your deposit above the cap comes back as a refund. |
| Fails | Your effective contribution is zero and your entire deposit is refundable in USDG. No LP is created. The round closes permanently. |
The exact test is on Clearing Condition.
3. The Cap Applies to You No Matter What
Only up to A_max of any single address's deposit is ever counted toward the round's target. At the current fixed FDV of 6,942 USDG, that ceiling is 138.84 USDG per address.
Deposit more than that and the excess is not counted, not allocated, and not lost — it is returned to you as part of your refund. There is no configuration, referral, or wallet behaviour that raises this ceiling.
4. Claiming
Settlement is computed off-chain over the frozen deposit set and committed on-chain as a single Merkle root. You then claim against it.
- Claims are pull-based. You call the claim function with your proof; the protocol never pushes tokens or refunds to you in bulk.
- Your token allocation and your USDG refund are independent leaves of the same commitment. Claim them together or separately, in any order. Claiming one never blocks or invalidates the other.
- A tampered proof, a proof against a stale root, a replayed claim, or a re-entrant call all fail deterministically.
Details on Settlement & Claims.
What You Cannot Do
Being explicit about this is the point of the design.
- You cannot improve your allocation by paying more gas.
- You cannot improve it by landing earlier in the window, or earlier in a block.
- You cannot improve it by splitting capital across addresses beyond the supply-wide 2% ceiling, which is enforced across all allocation buckets combined.
- You cannot lose principal to another participant's action. Refunds are non-negative by construction:
refund_i = z_i − e_i ≥ 0, always.