# architecture

Durianfun is built as a **factory pattern** with three layers. Each token you create gets its own fresh set of contracts, isolated from every other token.

## High-level diagram

```
┌─────────────────────────────────────────────────────────────┐
│  DuriandotfunFactory (one global contract)                  │
│  • Registry of all tokens                                    │
│  • Deploys new markets + tokens on `createToken()`           │
│  • Holds configurable fee params for future markets          │
│  • Owner-only admin (pause, setTreasury, updateFees)         │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           ▼  createToken()
┌──────────────────────────┴──────────────────────────────────┐
│  Per-token contracts (deployed atomically per createToken)   │
│  ─────────────────────────────────────────────               │
│                                                              │
│   BondingCurveMarket                                         │
│   • Holds all KUB raised                                     │
│   • Curve math for buys/sells                                │
│   • Graduates → deploys DurianAMM                            │
│                                                              │
│   DurianToken (ERC-20)                                       │
│   • Fixed 1B supply, minted once to the market               │
│   • No owner, no mint/burn, no blacklist — plain ERC-20      │
│                                                              │
│   DurianAMM (deployed at graduation)                         │
│   • Standard x·y=k pool                                      │
│   • Sealed — no add/remove liquidity functions               │
│   • Hardcoded 0.40% fee (cannot change)                      │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

## The Factory (V4.5)

The factory is the entry point for all token creation. It:

* Maintains a registry of every token created
* Enforces the anti-spam 0.1 KUB creation cost
* Passes the current default fee config to new markets
* Provides read helpers: `getTokens`, `getTokenInfo`, `getAmmPool`
* Accepts owner-only admin calls: `pause`, `setTreasury`, `setFees`, `updateMarketTreasury`, `updateMarketFees`, `rescueMarketTokens`

**Factory owner** = the Durianfun Treasury multisig. No single EOA has admin power post-deployment.

## The BondingCurveMarket

Each token gets its own market contract. It:

* Receives KUB from buyers, transfers tokens to them
* Accepts tokens on sells, transfers KUB back
* Charges 1.067% trading fee (split between treasury + creator rebate)
* Triggers graduation automatically when threshold is reached
* Refunds excess KUB if a buy would push past the graduation line

**Market owner** = the factory. The factory can:

* Update the market's treasury address (propagates to its AMM)
* Update the market's bonding fees (within 2% cap)
* Rescue stuck tokens post-graduation

**Market cannot** be paused, upgraded, or have its curve parameters changed.

## The DurianToken (ERC-20)

The token contract is **maximally decentralized**:

* ❌ No owner
* ❌ No mint function (besides constructor mint)
* ❌ No burn function
* ❌ No blacklist
* ❌ No tax-on-transfer
* ❌ No proxy / upgrade path

It is a vanilla ERC-20 with a fixed 1,000,000,000 supply. You can add it to MetaMask, list it on any DEX aggregator, send it to any wallet — it behaves like any standard ERC-20.

Stored alongside the standard ERC-20 fields:

* `imageUrl` — base64 data URI or external URL
* `creator` — original wallet that launched it (immutable)
* `market` — the BondingCurveMarket contract (immutable)

## The DurianAMM (post-graduation)

When a token graduates, its market deploys a fresh AMM contract. The AMM:

* Holds the token + KUB pair as an x·y=k pool
* Enforces 10-block cooldown after initialization (MEV protection)
* Charges 0.40% on every swap (0.30% treasury direct, 0.10% compounds in pool)
* Has **no add/remove liquidity functions** — pool is sealed
* Fees are hardcoded as `constant` — cannot be changed after deployment

**AMM owner** = the market that deployed it (can only propagate treasury updates). No direct admin functions exist.

## Ownership hierarchy (audit-relevant)

```
Durianfun Treasury multisig (owner of everything downstream)
  └─ Factory (admin functions gated by multisig)
       └─ Market (gated by factory)
            └─ AMM (gated by market, but no admin functions to call)
```

All factory-level ownership was transferred from the deployer EOA to the treasury multisig on 2026-04-14. Transfer transactions are on-chain and verifiable.

## What makes this safe

1. **Immutability** — no upgrade proxy, no delegatecall, no storage slots that get reinterpreted later
2. **Fee caps at bytecode level** — max 2% bonding fee is baked into `require()` in the market
3. **No liquidity removal paths** — the AMM literally has no function to withdraw funds
4. **Atomic graduation** — the curve → AMM transition happens in a single tx; no intermediate state where both or neither exists
5. **Deterministic addresses** — each market / token address is predictable pre-deployment, so integrators can pre-compute routes
6. **Full source verification** — all contracts verified on Kubscan, anyone can inspect bytecode vs source


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://durianandfun.gitbook.io/durianfun/durian-launchpad/resources/contracts/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.