Skip to main content
Forward-looking roadmap. This section describes the target design for the Areal protocol’s next evolution — community-driven strategy configuration executed by autonomous AI agents within on-chain enforced bounds. None of this is currently deployed. Live operations use team-operated bots under the constraints of the existing contracts described in Smart Contracts. This section exists to make the intended trajectory legible to contributors, integrators, and prospective ARL holders — not as a statement of current operational state.

In Plain Language

Nobody runs your money. The community writes the rules, software follows them, and the protocol makes breaking them impossible.
Most places where you put money work by trusting someone — a fund manager, a team, a committee — to decide what happens next. If they’re skilled and honest, you do well. If not, you hope. Your experience depends on their judgement, their integrity, and their availability. Areal is built on a different premise: remove the deciding human entirely. The work of managing a portfolio is split into three clear pieces, and none of them is “a person making a call”.

The community sets the rules

What the vault can hold, how much of each asset, when to rebalance, what risks are acceptable. Every rule change is voted on. Every rule is public.

Software follows the rules

Small specialized programs do the mechanical work — buying, selling, rebalancing. They have no opinions, no hunches, no shortcuts. They execute exactly what the community decided.

The protocol enforces the rules

Even if a program went rogue, or someone sneaked in a harmful change, the protocol itself refuses to perform anything outside the current rules. Breaking them is mathematically impossible.

Think of it like a smart home thermostat

You set the temperature you want — say 22°C. The thermostat doesn’t decide what temperature you want. It takes your setting and runs the heating to get there. It can’t set the house on fire — safety sensors intervene first. You can always turn it off. Areal’s vault works the same way, just scaled up:
Your homeThe Areal vault
You pick the temperatureThe community votes on the strategy
The thermostat runs the heatingHelper programs execute within the strategy
Safety sensors prevent firesProtocol rules prevent harmful transactions
You can always turn it offAnyone with 1% of ARL can halt the protocol by staking it
The heating system doesn’t decide what temperature you want. It does what you set, within physical safety limits. The vault is the same: community sets the goal, programs pursue it, the protocol keeps it safe.

What this means for you

No “trust us” required

You don’t have to trust a team’s judgement. Every decision is either a community vote with public results, or a mechanical action inside clearly published rules. Nothing happens because “the manager thought it was a good idea.”

You see changes before they take effect

When the community proposes a new rule, there’s a waiting period — 24 hours for small changes, 7 days for big ones. If you disagree, you have time to leave your position before it applies.

Nothing can touch your money

No team member, no program, no bad actor can move funds outside the current rules. Not because they promise not to — because the protocol won’t let them.

An emergency stop backed by skin in the game

Anyone holding 1% of total ARL supply can halt the protocol instantly by staking that ARL as a bond. The stake freezes while the team reviews whether the halt was justified. If it was — the stake is returned (plus a bounty for catching the problem). If it was a false alarm or abuse — the stake goes to the protocol treasury. Users never lose access to their tokens during a halt.

What a typical day looks like

1

Quiet days (most of the time)

Real-world assets in the vault earn yield — rent from property, interest from credit, royalties from IP. Your token’s underlying value grows automatically. No action from you required.
2

When the market drifts

If prices move enough, helper programs rebalance liquidity within the community-set rules. Nothing dramatic — just maintaining the target shape. You see it in events on-chain, nothing changes in your wallet.
3

When someone proposes a change

A community member submits a proposal — for example, “add this new real-estate project to the approved list.” The community evaluates it by trading on outcome markets (the one with the better expected result wins). If approved, the waiting period begins before the rule changes.
4

When something looks wrong

Anyone can flag anomalies through on-chain reports, community channels, or bug bounties. And anyone with conviction enough to stake 1% of ARL supply can trigger the emergency halt instantly. The stake is frozen for 7 days while the team (or, in the future, futarchy) decides whether the halt was justified. Justified → stake returned with a bounty. Spurious → stake forfeited to the Areal Treasury. Users keep full access throughout; only agent activity freezes.

What this approach is NOT

Not “AI picks your investments”

Helper programs don’t decide what to buy. They follow allocation targets the community has already set. If the rule says “no more than 25% in any one asset,” the program literally can’t exceed that — the protocol rejects the transaction.

Not “set and forget forever”

The strategy evolves as the ecosystem grows. You can participate in proposing or voting on changes, or you can just hold your tokens and let the community handle governance. Both are fine.

Not a replacement for due diligence

This approach reduces the risk of bad management — it doesn’t eliminate the risk that the underlying assets lose value, or that a new regulation affects the protocol, or that the market does something unexpected.

Not “trustless”

You still trust that the code does what it says, that real-world assets perform, that the community makes reasonable decisions collectively. What you don’t have to trust: any single person or team to manage your money well.

Want the technical version?

The rest of this page explains why this approach was chosen and how the pieces fit together. The Strategy, Agent, and Safety pages go deeper into exactly how each piece works. Read as much as you want — none of it is required to use the protocol safely.

The Problem With “Managed Portfolios”

The default framing for actively-managed DeFi vaults — “our team manages a portfolio for you” — carries three deep, compounding risks that Areal needs to eliminate before scale:

Regulatory exposure

The Howey Test’s “efforts of others” prong maps directly onto a discretionary human manager making allocation decisions. Under current US guidance, that framing is a strong signal toward security classification — regardless of what the documentation calls the token.

Trust concentration

A manager role with authority to swap, mint, or rebalance at will is a single point of failure. Compromise, collusion, or mis-judgement translates directly into holder losses. The blast radius is the entire vault.

Auditability gap

“Why did you make this trade?” has no on-chain answer when the decision lived in a human head. Post-hoc reasoning is not verification. Good outcomes become luck; bad outcomes become unprovable malpractice.

Narrative drift

Marketing says “decentralized”. Implementation says “we’ll handle it”. This gap widens over time as shortcuts accumulate, and eventually becomes indefensible to regulators, auditors, and holders alike.
Areal’s answer is not to hire better managers. It is to remove discretionary management from the system entirely by decomposing it into three layers with no single actor making business decisions.

The Three-Layer Separation

Strategy Layer — community via futarchy

  • Defines — what the protocol should do
  • Set by — ARL holders through decision markets
  • Governs — allocation caps, whitelists, yield splits, risk limits, concentration thresholds, venue approval
  • Change — two-tier timelock (24h operational / 7d critical)

Agent Layer — specialized AI agents

  • Defines — how and when, within the strategy bounds
  • Reads — StrategyConfig PDA as hard constraints
  • Does — optimization, timing, routing — never policy
  • Emits — structured audit events for every action
  • Limits — least-privilege; one agent per function

Contract Layer — on-chain invariants

  • Enforces — must-not. Every instruction validates against StrategyConfig before mutating state
  • Provides — kill switch, per-tx caps, slippage protection, circuit breakers, whitelist checks
  • Trust — none required beyond the contract code itself
The critical property: no layer alone can move value. Strategy can change parameters but cannot execute. Agents can execute but cannot exceed parameters. Contracts can reject, pause, or halt but cannot decide. An attacker or bad actor would need to subvert all three layers simultaneously to produce a harmful outcome — and each layer has distinct authority, distinct upgrade path, and distinct threat model.

Strategy Layer

Futarchy-governed parameters that bind agent behaviour. StrategyConfig PDA schema, timelock model, proposal templates.

Agent Layer

Four specialized agents with narrowly-scoped action surfaces. Permissions, audit trails, replacement lifecycle.

Safety & Invariants

On-chain enforcement, kill switch, circuit breakers, formal verification goals, incident response playbook.

Why This Matters

Under the Howey analysis, a token representing participation in a common enterprise with profits from the efforts of others typically falls into the security framework. Areal’s architecture directly challenges the “efforts of others” prong:
  • Strategy is not set by Areal Finance, a team, or any designated manager. It is set by ARL holders through futarchy markets — distributed decision-making with economic stake.
  • Execution is deterministic code. Agents are constrained optimizers, not discretionary actors. Their scope is published on-chain and verifiable by any participant.
  • Returns flow from the underlying real-world asset operations of each project’s DAO Ownership Company, not from Areal’s skill at picking or managing assets.
This is the same logic that shields infrastructure protocols like Ethereum or Solana itself — the protocol doesn’t manage anything, participants do. Areal aims for the same structural positioning for RWA. See Legal Architecture for the formal Howey-test analysis. The Agent Economy model strengthens that position materially.

Trust reduction

Every layer is designed to eliminate a class of trust assumption:

No discretionary manager

Nobody — not the Areal team, not a multisig, not a DAO committee — can decide “let’s swap OT_A for OT_B today”. Swaps happen because StrategyConfig permits them and an agent optimized timing within those bounds.

Least-privilege agents

Accumulation Agent cannot touch LP positions. LP Manager cannot mint RWT. Yield Harvester cannot change allocation. Compromise of one keypair affects one function — not the entire vault.

Parameter-bound execution

Even if every agent wallet were compromised simultaneously, the worst-case damage is bounded by the current StrategyConfig (daily volume caps, slippage limits, concentration bounds). Governance can kill-switch within minutes.

Verifiable change history

Every StrategyConfig update went through a published futarchy proposal with conditional markets. Every agent action emits an event referencing the config version it executed against. Forensic reconstruction is exact.

Auditability by design

The system produces a complete, machine-readable audit trail:
Proposal #142  →  StrategyConfig v23  →  AgentAction #8841  →  State delta
  (ARL holders)    (timelock: 24h)       (AccumulationAgent)    (vault +500 RCP)
Every agent action links back to the exact StrategyConfig version it read, which links back to the futarchy proposal that set that version. No action is ever “because Alice thought it was a good idea” — every action has an on-chain provenance chain.

Blast radius containment

Four specialized agents instead of one monolithic manager means:
  • Compromise of Accumulation Agent cannot drain Nexus LP positions
  • Compromise of Yield Harvester cannot change which OTs are whitelisted
  • Compromise of Rebalancer cannot exceed max_daily_swap_volume
  • Compromise of all four still cannot violate StrategyConfig or kill-switch
Each agent is individually replaceable by governance without affecting the others.

The V1 → V2 Transition

Honest naming. Current deployment does not include AI agents. It includes team-operated bots running the mechanical roles this section will eventually cover. Using the word “agent” for a deterministic script would be marketing dishonesty. The framework below describes what the role becomes when the system matures — and the guardrails that already make that transition safe.

Current state (V1)

  • Rebalancer bot (team keypair) calls grow_liquidity / compress_liquidity on deviation triggers
  • Vault Manager bot (team keypair) calls vault_swap to acquire OTs per governance-approved accumulation targets
  • Nexus Manager bot (team keypair) calls nexus_swap / nexus_add_liquidity / nexus_remove_liquidity
  • Cranks (permissionless) handle yield claims, revenue distribution, merkle publication
  • Governance (Team Multisig as current authority) approves all strategy parameter changes directly — not yet via conditional markets
All bots already have the least-privilege constraint: none can extract funds, all operate through instructions that validate against on-chain config.

Target state (V2)

  • Strategy Layer: every parameter governed by futarchy conditional markets, two-tier timelock enforced by contract
  • Agent Layer: four specialized autonomous agents replace the current team-operated bots; their strategy is read from StrategyConfig PDA
  • Contract Layer: StrategyConfig enforcement on every mutating instruction; richer circuit breakers; formal verification of critical invariants

Transition path

1

Phase 1 — StrategyConfig scaffolding

Deploy StrategyConfig PDA for each managed surface (RWT Vault, Nexus, Treasury). Existing bots begin reading it as hard constraints. Parameters continue to be set by Team Multisig during this phase.
2

Phase 2 — Futarchy-driven updates

Once Futarchy V2 (described in Governance & Futarchy) ships, all update_strategy_config calls must originate from a resolved futarchy proposal rather than direct multisig execution. Team Multisig retains only pause / kill-switch authority.
3

Phase 3 — Specialized agents

Team-operated bots are retired one function at a time, replaced by specialized AI agents that optimize within StrategyConfig bounds. Each replacement is itself a governance decision with a trial period and reversibility.
4

Phase 4 — Formal verification

Critical invariants (fund conservation, StrategyConfig enforcement, kill-switch reachability) are formally verified. Security audits move from “trust the team” to “trust the proofs”.
Each phase is reversible. If Phase 3 agents underperform team bots on measurable dimensions (slippage, capital efficiency, yield capture), governance reverts to bot operation. The system is designed to be evolutionary, not dogmatic.

What This Section Does Not Claim

Not deployed

Nothing in Strategy Layer / Agent Layer / Safety pages is currently live. Use the existing contract specs in Contracts as the source of truth for current behaviour.

Not a commitment to dates

Phase progression depends on audit outcomes, governance decisions, and technical readiness. No dates are attached. No promises are made.

Not “AI does investing”

Agents are constrained optimizers, not discretionary managers. They do not pick what to buy — they execute how to buy what governance decided.

Not a substitute for due diligence

This framework reduces operational risk — it does not eliminate RWA-level, legal, or macroeconomic risk. See Risk Disclosure.

Further Reading

Strategy Layer

How futarchy configures the bounds agents operate within

Agent Layer

Four specialized agents and their action surfaces

Safety & Invariants

On-chain enforcement, kill switch, circuit breakers