Smart contracts and basket accounting

Lots is designed to put token rights, backing and settlement constraints into contracts. The website helps users choose and review actions; it must not be the source of truth for balances or entitlements.

This is an architecture explanation from PRD v4, not an ABI reference or claim of verified deployed code. Contract addresses, signatures and numerical integration evidence remain release deliverables.

Responsibility map

Component	Intended responsibility
Asset registry and factories	Asset admission, canonical recipes and official launch identities
Basket vault	Component custody, fully funded basket issuance and complete normal redemption
Launch factory and meme token	One-time issuance, launch commitment and fixed identity
v4 policy and principal locker	Approved ranges, fees, authenticated caps and permanent principal protection
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

Separating these roles makes the promises inspectable. A fee balance must not be confused with vault backing, and a router credit must not be treated as a component already delivered to a vault.

Healthy basket arithmetic

Let D be the number of raw basket units per whole basket token, S total raw basket supply, s the transaction amount in raw basket units, and u_i the raw units of component i per whole basket 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. Use full-precision integer arithmetic and validate every component's decimals and issuer units. The engineering default for meme and basket tokens is 18 decimals, subject to validation.

A deliberately small rounding example

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

• The required reserve is floor(3 × 4 / 10) = 1 atomic unit.
• Minting 3 raw basket units requires ceil(3 × 4 / 10) = 2 atomic units.
• Redeeming 3 raw basket 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; users should 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. Do not silently admit fee-on-transfer or rebasing behavior that breaks the quantity model.

Donations and rounding surplus do not rewrite recipes or create an administrator or last-holder windfall. Healthy rounding rules also do not replace the separate, still-unvalidated recovery liability model.

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 a Lots basket is minted, any relevant accounting credits must become actual deposited component balances. Routers must clear all currency deltas, restrict adapters and callback authority, and refund only transaction-local residuals.

Rotation additionally validates both registered launches and their official pools against the immutable quote identities. Matching user-provided strings or an arbitrary matching address cannot establish eligibility.

What independent verification needs

A release needs verified contract identities and interfaces, tested role boundaries, accounting and integration evidence, and a minimal client for healthy in-kind operations without the main website, indexer or offchain signature service.

That client is a required product deliverable, not included as fabricated example calldata in these docs. Until the interfaces are pinned and validated, this site should not publish guessed write calls or receiving addresses.

See security and permissions for what operators may do, and product status for evidence still outstanding.