Skip to main content

Overview

HISTORICAL - describes the abandoned tournament / forecast-AMM design

This page documents the pre-migration architecture (TournamentManager, matchday-gated trading, on-chain ForecastMarket AMM). None of it exists in the current system: tournaments were replaced by instant 1v1 prestige-ladder battles, prediction markets are off-chain parimutuel in non-redeemable in-game currency, and the contract suite is Charter v2 + the Uniswap v4 venue. For current rules see the Platform Rules page; for current architecture see the repo's docs/architecture/ and my-dapp-contracts/docs/ARCHITECTURE.md.

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​