System diagram
┌──────────────────────────┐
│ USER (wallet client) │
│ Phantom / Solflare / etc │
└────────────┬─────────────┘
│
│ Anchor TS client
▼
┌──────────────────────────┐
│ Next.js dApp │
│ pages: swap / lend / │
│ stake / farm / vote │
└────────────┬─────────────┘
│ RPC (signed tx)
▼
┌────────────────────────────────────────────────────────┐
│ SOLANA RUNTIME │
│ │
│ ┌──────────────┐ ┌───────────────────┐ │
│ │ idea-govern. │◄────────│ idea-token │ │
│ │ propose/vote │authority│ SPL mint+vesting │ │
│ └──────┬───────┘ └─────────┬─────────┘ │
│ │ │ │
│ authority│ ┌──────────────────────┘ veIDEA balance │
│ ▼ ▼ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ idea-staking │ │ idea-swap │◄─┐ │
│ │ simple + ve │ │ CPMM x·y=k │ │ LP tokens │
│ └────────┬───────┘ └────────┬───────┘ │ │
│ │ fee distr. │ fees │ │
│ │ ▼ │ │
│ │ ┌────────────────┐ │ │
│ └────────────┤ fee-aggregator ├─┘ │
│ └────────┬───────┘ │
│ │ │
│ ┌──────────────────┐ │ │
│ │ idea-lending │───────────┘ │
│ │ reserves+cTokens │ fees │
│ └──────────────────┘ │
│ │
│ ┌──────────────────┐ │
│ │ idea-farms │◄── LP token from idea-swap │
│ │ MasterChef-ish │ emissions from idea-token │
│ └──────────────────┘ │
│ │
│ ┌──────────────────┐ ┌────────────────┐ │
│ │ Pyth │◄──prices──┤ idea-lending │ │
│ │ Switchboard │ └────────────────┘ │
│ └──────────────────┘ │
└────────────────────────────────────────────────────────┘
Programs
| Program | Address (devnet) | Source |
|---|---|---|
idea-token |
TBD on deploy | programs/idea-token.md |
idea-staking |
TBD on deploy | programs/idea-staking.md |
idea-swap |
TBD on deploy | programs/idea-swap.md |
idea-lending |
TBD on deploy | programs/idea-lending.md |
idea-farms |
TBD on deploy | programs/idea-farms.md |
idea-governance |
TBD on deploy | programs/idea-governance.md |
Cross-program invocation (CPI) map
| Caller | Callee | Purpose |
|---|---|---|
idea-staking |
idea-token (SPL) |
Transfer IDEA into/out of lock vault |
idea-staking |
idea-token (SPL) |
Distribute fee revenue to lockers |
idea-swap |
idea-token (SPL) |
Mint LP tokens |
idea-farms |
idea-swap LP mint |
Pull staked LP balances on harvest |
idea-farms |
idea-token (SPL) |
Emit IDEA rewards |
idea-lending |
Pyth / Switchboard | Read oracle prices |
idea-governance |
any program | Execute timelocked instruction (set parameter, upgrade) |
idea-governance |
idea-staking |
Snapshot veIDEA balances at vote start |
Account layout strategy
Across all programs we use Anchor PDAs for deterministic address derivation, never raw keypairs. PDA seeds are documented per-program in the specs. Common patterns:
[b"config"]— singleton configuration account per program[b"market", asset_mint]— per-asset lending market[b"pool", token_a, token_b]— per-pair swap pool[b"position", user, market_or_pool]— user's position[b"vault", market]— token custody account for a market[b"lock", user]— user's veIDEA lock state
Upgrade authority
All programs are deployed with upgrade authority = idea-governance program PDA. This means:
- No multisig or EOA can deploy a new version on a whim.
- Upgrades require a passed governance proposal.
- Proposal must clear the 48h timelock before the upgrade instruction executes.
Exception: during Phase 0–2 (devnet + early mainnet), upgrade authority is held by a 5-of-9 multisig of doxxed contributors. Transition to full on-chain governance is hard-coded as a Phase 3 milestone.
Failure modes & recovery
| Failure | Detection | Recovery |
|---|---|---|
| Pyth feed stale > 60s | Per-instruction check | Lending enters guarded mode; only repays + conservative liquidations |
| Pyth/Switchboard disagree > 1% | Per-instruction check | Lending pauses new borrows for affected asset |
| Governance proposal contains malicious payload | Emergency pause council (5-of-9) vetoes during timelock | Affected program-set frozen until next vote |
| LP token reentrancy attempt | Anchor Accounts constraint |
Transaction reverts at constraint check |
| Insurance fund depleted | TVL-anchored alert | Emergency proposal to backstop from treasury |
Why six programs and not one monolith?
Solana programs have a 10MB max size and audit cost scales super-linearly with surface area. Modular programs:
- can be audited independently in parallel;
- can be upgraded independently without affecting unrelated modules;
- compose cleanly via CPI, which Solana is optimized for;
- present smaller blast radius if any single program is compromised.
This is the same lesson EVM converged on (e.g., Compound v2 → Compound III splits, Aave's plugin architecture).