Overview

This architecture pack captures the end-to-end D4L runtime: token launch, fundraising, graduation, matchday-gated trading, and on-chain battle forecasting.

How to read

• Start with system context and containers to align on boundaries.
• Review contract components and permissions to understand on-chain authority.
• Use the state machine and sequence diagrams to reason about lifecycle behavior.
• Confirm event mappings before implementing indexing or analytics.

Core architecture facts

D4L uses three separate AMM domains:

• BondingCurve AMM: pre-graduation token fundraising/trading.
• DEX pools (Curve-style): post-graduation token liquidity.
• ForecastMarket AMM (FPMM-style): match forecasting with collateral <-> outcome shares.
• Forecasting positions are modeled as PositionToken (ERC-1155) YES/NO/INVALID shares per match market.
• Matchday windows gate both token trading and forecasting for tournament tokens.

On-chain vs off-chain responsibilities

• On-chain is canonical for custody, trading settlement, transfer gating, match results, and forecast settlement/redemption.
• Off-chain (API, Worker, Postgres) is for UX and speed: indexing, quote/simulation reads (eth_call), tx tracking, realtime feeds, and notifications.
• API and Worker are the only Postgres writers.

Diagram index

• System context
• Container view
• Contracts component view
• Graduation sequence
• Token lifecycle state machine
• Events + DB mapping
• Permissions + threats