Protocol Architecture
3.1 Performance-Bond Model#
At the core of LAMA is the performance-bond. Let denote the stake amount (in LAMA tokens) posted by trader when publishing agent .
This stake serves as collateral and determines the maximum reward and risk exposures:
- If the agent performs well relative to a benchmark, a portion of is released as reward to investors.
- If it performs poorly, part of is slashed.
The protocol does not control the trader's off-chain capital; only the on-chain stake is at risk.
3.2 Dual-Token Structure#
There are two classes of tokens:
| Token | Type | Purpose |
|---|---|---|
| LAMA Token () | ERC-20 | Platform's native asset used for staking, governance and payment of rewards |
| Agent Tokens () | ERC-1155 | For each agent , two fungible tokens representing long and short positions on that agent's net performance over a given settlement period |
Investors obtain exposure to the agent's return by purchasing these tokens using LAMA; at settlement, they either receive additional LAMA or forfeit part of their stake depending on the agent's performance.
3.3 Long/Short Performance Market#
Each agent has two liquidity pools: a long pool and a short pool.
Let and denote the total amount of LAMA supplied to the long and short pools of agent at time .
- When an investor provides LAMA to the long pool, they receive tokens representing a share of the pool.
- Similarly, supplying LAMA to the short pool yields tokens.
At settlement, rewards or penalties are distributed between the pools based on the agent's net return over the period:
- If — the long pool receives a reward from the trader's stake proportional to , while the short pool forfeits part of its collateral.
- If — the short pool receives a reward and the long pool forfeits.
This zero-sum transfer ensures investors can hedge or speculate on performance without requiring custody of the underlying assets.
3.4 Off-Chain Oracle Layer#
Since trading occurs on external exchanges, a reliable oracle is required to feed verified performance data to the smart contract.
┌─────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ VibeTrade API │────→│ Oracle Service │────→│ PerformanceOracle│
│ (Off-chain) │ │ (Off-chain) │ │ (On-chain) │
└─────────────────┘ └──────────────────┘ └──────────────────┘
The oracle aggregates API data from multiple sources, verifies trade execution and computes metrics such as cumulative return, drawdown and volatility.
To prevent manipulation, the oracle layer may be decentralized with multiple data providers and a dispute resolution mechanism.
3.5 Smart Contract Architecture#
contracts/
├── token/
│ └── LAMA.sol # ERC-20 LAMA token
├── core/
│ ├── AgentRegistry.sol # Agent registration & management
│ ├── StakingVault.sol # Trader LAMA staking
│ ├── PerformancePool.sol # Long/Short investment pools
│ └── Settlement.sol # Settlement logic
├── oracle/
│ └── PerformanceOracle.sol # Performance verification oracle
└── governance/
└── LAMAGovernor.sol # Governance (Phase 3)
Access Control#
| Function | Caller |
|---|---|
registerAgent | Any wallet (must own VibeTrade runner) |
stake / unstake | Agent owner only |
depositLong / depositShort | Any wallet |
submitPerformance | Oracle multi-sig only |
settle | Permissionless (triggered by oracle submission) |
claim | Position holder only |