Autonomous Swarms.
Cryptographic Guardrails.

Because a sub-account constrains how much sits in the account — never where the money may go. Three structural gaps make "capped sub-account" a weaker guarantee than it looks:

1. Access keys scope method names, never arguments. A NEAR access key is a tuple of (receiver_id, method_names, allowance). The runtime checks the method being called; it never parses that method's JSON arguments. A key scoped to usdc.testnet / ["ft_transfer"] is therefore a key that can move any amount to any recipient — ft_transfer({"receiver_id": "hacker-drain.testnet", "amount": "..."}) is a valid call for that key. A recipient allowlist cannot live in a key; it can only live in a contract that owns the funds.
2. Splitting liquidity destroys the global ceiling. N sub-accounts means N independent balances. There is then no single on-chain place that enforces your real fleet-wide limit: to know the swarm spent at most 5 Ⓝ today you must aggregate off-chain — i.e. trust a keeper bot. Echoes keeps one treasury and enforces the per-agent daily cap and the vault daily cap against the same counters inside the same receipt, so the global ceiling is a storage invariant, not a monitoring claim.
3. The balance is all-or-nothing. With a sub-account the pre-loaded balance is the only real limit, which forces a bad choice: fund it small and the agent dies mid-task on an unhelpful "insufficient balance" (or silently retries and burns gas); fund it large and one compromise takes everything at once, because nothing caps the individual transfer. Echoes separates "funded" from "spendable": the vault holds the capital, and policy decides what leaves per transaction and per day.

The Echoes answer: the agent never holds the money. It holds a FunctionCall key on allowance-swarm.testnet scoped to ["spend", "spend_as"], with no transferable allowance — protocol rules already forbid that key from attaching a deposit. Every payout must pass assert_recipient() plus the per-agent and vault arithmetic ceilings before Promise::transfer is even constructed. Worst case for a fully compromised agent key: at most per_tx NEAR, to an address you approved in advance, with the attempt sitting in get_log().

Honest limit: this protects the funds in the vault. A leaked agent key can still burn its own gas allowance on reverted calls — that is bounded by the key's gas allowance (≤ 0.25 Ⓝ) and by revoke_agent, not by Echoes' policy engine.

Every guardrail in spend_as is enforced before any transfer is scheduled. When a check fails the contract traps (Rust fail() → unreachable), so the whole receipt reverts: no Promise::transfer is ever created, spent_today is not incremented, no log entry is written, and zero yoctoNEAR moves. A prompt-injected agent therefore learns nothing and gains nothing per attempt — every retry costs it gas and fails identically.

Reverting alone would let a compromised key keep retrying forever, so Echoes adds an explicit owner-controlled kill path: revoke_agent(agent_id) flips active = false in persistent storage, and reactivate_agent / set_paused are gated by assert_owner(). Both are verifiable on this testnet account: revoke_agent and reactivate_agent transactions are listed below with block-level receipts.

Note: revocation is owner-triggered, not automatic. We deliberately did not market an "auto-revoke on breach" primitive — a contract cannot safely self-disable a key on a reverted receipt, and doing so non-atomically would require a separate keeper.

Every spend_as(amount, recipient, memo) call traverses five sequential verification gates — the agent is identified by the signer_account_pk() of the calling key, not by a passed-in id:

1. GATE 01 (Protocol Key Scope & Predecessor): NEAR Runtime validates the ed25519 key is restricted to spend / spend_as with gas ≤ 0.25 NEAR.
2. GATE 02 (Circuit Breaker): Asserts the vault is not paused by the owner (!self.is_paused).
3. GATE 03 (Agent Active Status): Confirms the agent exists and agent.is_active == true.
4. GATE 04 (Recipient Allowlist): Confirms self.allowlist.contains(&recipient). Otherwise the call reverts before any transfer is scheduled.
5. GATE 05 (Dual Velocity Caps): Enforces three arithmetic ceilings simultaneously: amount <= agent.per_tx (0.20 Ⓝ), agent.spent_today + amount <= agent.daily (1.00 Ⓝ), amount <= vault.per_tx (0.50 Ⓝ), and vault.spent_today + amount <= vault.daily (5.00 Ⓝ).

Administrative methods (reactivate_agent, set_paused, add_to_allowlist, and register_agent) are protected by two independent barriers:

First, at the NEAR Runtime level, each agent's FunctionCall access key explicitly whitelists only ["spend", "spend_as"]. Any transaction signed by an agent key attempting to invoke reactivate_agent or set_paused is rejected by NEAR validators before WASM execution even begins (demonstrated in Preset 05). Second, inside the contract, assert_owner() verifies env::predecessor_account_id() == self.owner_id.

On NEAR Protocol, transaction nonces are tracked per AccessKey rather than per account. By provisioning a dedicated ed25519 FunctionCall Access Key for each autonomous worker in the swarm (agent-alpha, agent-beta), multiple agents can sign and broadcast transactions concurrently in the same block with zero nonce contention—while the Echoes contract atomically serializes their cumulative deductions against the shared Global Vault Cap.

Hackathon Judges can verify Echoes in three ways with zero local setup required:

• 1. Testnet Console & 5-Gate Playground (In-Browser): Open the Swarm Security Console to simulate any agent spend or admin call against live testnet state, or connect MyNearWallet (testnet) / a scoped agent key to broadcast for real. For the gate-by-gate walkthrough, click "RUN SIMULATED SWARM DEMO" in the Hero or test all 5 presets in Section 03 and copy ready-to-run near-cli-rs commands.
• 2. On-Chain Verification on NearBlocks Testnet Explorer: Inspect testnet.nearblocks.io/address/allowance-swarm.testnet to verify the deployed WASM contract, scoped FunctionCall access keys, and real Testnet transaction receipts.
• 3. Python Swarm Agent Suite & audit.jsonl: Run python3 allowance/agent/swarm_demo.py or python3 allowance/agent/verify_vault_cap.py to broadcast live multi-agent transactions and generate cryptographically linked JSONL audit trails.

Echoes is architected as the foundational policy-enforcement layer for autonomous agents across the entire NEAR AI ecosystem:

• NEAR Chain Signatures (MPC) Guardrails: Before the Echoes Vault requests a threshold signature from v1.signer-prod.testnet to sign an EVM, Bitcoin, or Solana payload on behalf of an agent, the payload must pass Echoes' 5-Gate velocity and destination allowlist checks.
• NEP-141 stablecoin policies (USDC / USDT) — roadmap, not in this build: real agents pay in stablecoins, and today spend_as schedules only a native Promise::transfer. Shipping NEP-141 spending needs three concrete changes we have scoped but deliberately not faked: a spend_ft(amount, token, recipient, memo) path that calls ft_transfer on the token contract (with the same assert_recipient allowlist), a per-token spent_today counter keyed by token contract account, and a one-time storage_deposit so the vault can hold the token balance. Gates 02–05 already operate on plain u128 integers and are token-agnostic, so the policy struct applies per token unchanged.
• NEAR Intents Solver Verification: Agents can submit bounded swap or compute intents where Echoes verifies maximum slippage and daily notional caps before committing solver settlement — the same counters, extended to a notional ceiling so an intent can be rejected before a solver ever quotes.