Protocol Architecture

3.1 Performance-Bond Model#

At the core of LAMA is the performance-bond. Let SiS_i denote the stake amount (in LAMA tokens) posted by trader ii when publishing agent ii.

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 SiS_i is released as reward to investors.
  • If it performs poorly, part of SiS_i 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:

TokenTypePurpose
LAMA Token (LL)ERC-20Platform's native asset used for staking, governance and payment of rewards
Agent Tokens (Ai,long,Ai,shortA_{i,\text{long}}, A_{i,\text{short}})ERC-1155For each agent ii, 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 LtiL_t^i and StiS_t^i denote the total amount of LAMA supplied to the long and short pools of agent ii at time tt.

  • When an investor provides xx LAMA to the long pool, they receive Ai,longA_{i,\text{long}} tokens representing a share of the pool.
  • Similarly, supplying LAMA to the short pool yields Ai,shortA_{i,\text{short}} tokens.

At settlement, rewards or penalties are distributed between the pools based on the agent's net return rir_i over the period:

  • If ri>0r_i > 0 — the long pool receives a reward from the trader's stake proportional to rir_i, while the short pool forfeits part of its collateral.
  • If ri<0r_i < 0 — 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#

FunctionCaller
registerAgentAny wallet (must own VibeTrade runner)
stake / unstakeAgent owner only
depositLong / depositShortAny wallet
submitPerformanceOracle multi-sig only
settlePermissionless (triggered by oracle submission)
claimPosition holder only