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 BNB, or supported Stock Tokens where an approved BSC conversion route is enabled. BNB is credited in BNB units; wrapping it as WBNB is a 1:1 representation change. Stock Token deposits are swapped through the supported Stock Token/WBNB market. Only the BNB-equivalent amount actually received is credited, after any conversion costs — never a quoted or 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 credited BNB balance is refundable in BNB. 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 converted FDV of approximately 8.974905946 BNB, that ceiling is approximately 0.179498119 BNB per address. Exact values are in Parameters & Constants.
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 BNB refund are independent claim rights from the same committed leaf. 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.
- The 2% cap applies separately to each address. Multiple wallets controlled by one person are not identified by this rule alone.
- The BNB refund cannot be negative under the allocation formula. This does not protect its dollar value or reimburse gas and conversion costs:
refund_i = z_i − e_i ≥ 0, always.