Smart contracts and Lot accounting

Lots contracts enforce token rights, backing and settlement rules. The application presents the action and transaction review; onchain state records the resulting balances and entitlements.

This page covers current fixed-Lot contracts. See deployments for identities and verification status.

Responsibility map

Component	Responsibility
Asset registry and factories	Asset admission, canonical recipes and official launch identities
Lot vault (Basket)	Component custody, fully funded Lot-token issuance and complete normal redemption
Launch factory and launch token	One-time issuance, launch commitment and fixed identity
Launch hook and principal locker	Fixed trading fees, early buying limits and permanently locked launch principal
LotFlow hook and shared liquidity manager	Lot/USDG swaps, shared liquidity deposits and position accounting
Routers	Complete signed routes, authorized callbacks, final output and refunds
Fee escrow	Independent recipient claims and separation of committed buybacks
Buyback executor	Bounded same-launch purchases and actual burns
Recovery ledger	Per-component entitlements and later distributions
Indexer and interface	Readable views derived from authoritative contract state and events

Each contract has a defined responsibility. Fee balances, router credits and component backing have separate accounting; only components delivered to a Lot vault count toward its backing.

Fee accounting preserves each collected asset. Fee allocations cannot draw from vault backing or locked principal.

Healthy Lot arithmetic

Let D be the number of raw units per whole Lot token, S total raw Lot-token supply, s the transaction amount in raw Lot units, and u_i the raw units of component i per whole Lot token.

mint input i       = ceil(s × u_i / D)
redeem output i    = floor(s × u_i / D)
required reserve i = floor(S × u_i / D)

Mint inputs round up, redemption outputs round down, and healthy aggregate liability also rounds down. Calculations use each component’s decimals and raw token units. Launch and Lot tokens use 18 decimals.

Rounding example

Assume D = 10, S = 3 and one component quantity u_i = 4 atomic units per whole Lot token.

• The required reserve is floor(3 × 4 / 10) = 1 atomic unit.
• Minting 3 raw Lot-token units requires ceil(3 × 4 / 10) = 2 atomic units.
• Redeeming 3 raw Lot-token units pays floor(3 × 4 / 10) = 1 atomic unit.

A component balance of 1 meets that healthy aggregate liability. Treating the fractional remainder as another full unit would incorrectly show a shortfall. If the balance is 2, the extra unit is displayed as surplus, not a withdrawal entitlement.

Across any partition of the supply, the sum of individually floor-rounded redemption outputs cannot exceed the floor-rounded aggregate liability. Splitting into very small redemptions can return less because each rounds separately; review exact atomic outputs.

Coverage is per component

An excess of X cannot cancel a deficit of Y. Check actual transfer balance changes and each component's required reserve independently. Fee-on-transfer or rebasing behavior can break the quantity model and does not qualify merely because the asset uses an ERC-20 interface.

Donations and rounding surplus do not rewrite recipes or create an administrator or last-holder windfall. Healthy rounding rules do not replace the separate recovery model. See recovery for component-specific entitlements.

Atomic routes and actual delivery

Uniswap v4 flash accounting records obligations during execution and requires outstanding deltas to be resolved before completion. It is a settlement mechanism, not a source of backing assets. Uniswap flash accounting.

Before Lot tokens are minted, every required component must reach the vault. Routers settle outstanding currency balances, authenticate callbacks and refund only assets left over from that transaction.

Rotation validates that both launches belong to the same factory and that their official pools use the same immutable quote identity. Matching user-provided strings or an arbitrary matching address cannot establish eligibility.

Check contract identity

Verify the chain, contract address and role before granting an allowance or signing a transaction. A familiar contract name or token symbol is not sufficient identification.

See deployments for addresses, security and permissions for operator powers, and product availability for access and audit status.