00 / Executive abstract
Autonomy needs an enforceable operating boundary.
AIMB-X proposes an operating boundary in which autonomous software has an explicit identity, declared capabilities, enforceable permissions, and an inspectable outcome record.
An agent should not need a new bespoke integration for every decentralized exchange, prediction market, or data venue. A capital provider should not have to trust that an offchain policy will be obeyed during volatility. AIMB-X addresses both problems with a proposed protocol-neutral bridge between machine intent and market execution.
Before a request would be routed, the proposed contracts would evaluate the agent’s lifecycle state, registered capability, transaction limit, rolling budget, drawdown, and target-market permission. Accepted outcomes would be recorded and could feed a bounded reputation score. The design goal is delegated execution without unconstrained authority.
- A four-layer architecture for identity, policy, execution, and settlement.
- A standard market-adapter interface for protocol-specific integrations.
- Hard risk controls that are evaluated before capital moves.
- A verifiable performance history and recency-weighted reputation model.
01 / Market bottlenecks
Why autonomous finance still lacks dependable infrastructure.
Integration fragmentation
Agents currently need custom adapters for each market. Engineering effort expands with every venue, interfaces diverge, and there is no neutral request surface that can be reused across protocols.
The accountability gap
Most agent activity offers no shared record of identity, declared capability, total risk exposure, policy adherence, or historical results. Performance claims remain fragmented and difficult to verify.
The capital trust deficit
Offchain instructions are advisory. They cannot provide the hard guarantees required for delegated capital. Risk boundaries need to be checked in the same execution path that moves the assets.
Make disallowed execution technically unavailable, not merely discouraged.
The proposed architecture combines identity, permissioning, routing, settlement, and reputation inside one modular contract system.
02 / Protocol architecture
Four layers, one accountable execution path.
- Agent registryIdentity, capability taxonomy, a registration bond, and lifecycle controls.
- Guardrail and permissionCapital limits, drawdown controls, market whitelists, timelocks, and circuit breakers.
- Bridge and executionA standard request interface with dynamic routing through pluggable market adapters.
- Settlement and reputationOnchain outcome records and a bounded, recency-weighted scoring engine.
Agent registry
The registry is proposed as the root identity and authorization layer. Each profile would record an owner address, controlled capability tags, a registration bond, and a lifecycle state: active, paused, circuit-tripped, or retired. A bond raises the cost of registration; it does not by itself prevent Sybil identities.
Guardrail and permission layer
Capital limits would sit on the execution path, not in separate monitoring. The proposed contracts would evaluate the following boundaries before forwarding a request:
- Per-transaction limitHard ceiling on capital committed by one request.
- Rolling budgetAggregate capital allowance evaluated over a 24-hour period.
- Drawdown thresholdCumulative-loss boundary that can trip the agent circuit breaker.
- Market whitelistLeast-privilege list of protocols an agent may reach.
- Timelocked changesTwo-day delay for guardrail changes; emergency halts remain immediate.
Bridge, settlement, and reputation
The Bridge would expose the standard request entrypoint and delegate market-specific behavior to adapters. After execution, settlement would record profit and loss and update a score derived from observed results rather than a self-reported claim.
03 / End-to-end execution
From machine intent to recorded outcome.
The proposal makes the control path explicit so that every accepted action could be reconstructed from request to settlement.
- 01Agent request
Submit action, market identifier, amount, and asset through the Bridge.
- 02Policy validation
Verify identity status, capability, available budget, drawdown, and market permission.
- 03Adapter execution
Route an accepted request to the selected market adapter against onchain price data.
- 04Settlement
Record the outcome and update the agent’s reputation from observed performance.
Agent request → Bridge validation → Guardrail check → Market adapter → Settlement and reputation
04 / Core specification
A small interface with hard policy around it.
Market adapter interface
Pluggable adapters would standardize the request surface while preserving market-specific implementation behind a common call boundary.
Reputation scoring engine
The proposed score is bounded between 0 and 1,000 and initializes at 500. Each result would move the current score toward a performance-derived target using a step ratio of 0.3, while a delta cap of 100 would limit any single update.
ΔS = min(100, 0.3 × (target score − current score))
Recent transactions would carry greater weight so strategy degradation could become visible without allowing one outcome to rewrite an agent’s full history.
05 / Capability taxonomy
Permissions use controlled, inspectable labels.
Capability tags would declare the work an agent is authorized to perform. The proposed initial taxonomy covers six autonomous-market functions:
- sentiment-analysisProcess offchain social and news feeds into sentiment metrics.
- arbitrage-executionExecute against liquidity and price differences across venues.
- price-predictionGenerate directional market forecasts.
- market-makingProvide automated bidirectional liquidity quotes.
- risk-hedgingExecute automated delta- or gamma-neutral hedging strategies.
- portfolio-rebalancingAdjust multi-asset baskets against a defined allocation policy.
06 / Token and ecosystem
Align the participants around accountable execution.
The paper proposes an AIMB-X token to coordinate registration, capital allocation, adapter demand, and assurance work. It does not publish a token contract, supply schedule, allocation, or governance implementation; this section is an economic design direction, not a live asset description.
Agent developers
Would register agents, post a bond, publish capabilities, and receive fees when capital is allocated.
Capital providers
Would delegate liquidity under contract-enforced limits and retain an immediate emergency stop.
Market protocols
Would implement adapters for standardized autonomous order flow.
Auditors and validators
Would review adapter safety under a separately defined assurance program.
07 / Implementation and roadmap
Begin with a bounded testnet implementation.
Version 1.1 names Avalanche Fuji as the reference environment for future testnet work. Public materials do not currently include a Market Bridge source repository, contract addresses, a deployment transaction, a block number, or verified source. Audit, bounty, mainnet, and governance remain proposed later stages.
- Phase 1Specification
Architecture design, mathematical specification, and technical whitepaper.
- Phase 2Public reference implementation
Publish source, tests, build artifacts, and exact Fuji deployment identifiers for independent review.
- Phase 3Independent assurance
Third-party smart-contract audits and a public bug bounty.
- Phase 4Capped mainnet launch
Verified adapters and deliberately bounded institutional capital pools.
- Phase 5Protocol expansion
DAO transition, multichain support, and oracle integration.
08 / Technical FAQ
Short answers to implementation questions.
What would AIMB-X standardize?
The proposal defines a common request path between autonomous software and supported decentralized markets. An adapter would translate that request into market-specific execution.
Who would control delegated capital?
In the proposed design, the capital provider defines enforceable limits. The Bridge path would reject requests outside transaction caps, rolling budgets, drawdown thresholds, or the market whitelist.
Could a risky agent be stopped immediately?
The proposal makes emergency halts immediate. Less urgent guardrail changes would use a two-day delay so material permission changes are visible before they take effect.
How would reputation be calculated?
The proposed score is bounded from 0 to 1,000, begins at 500, and moves toward a performance-derived target. Each update is capped while recent outcomes receive greater weight.
Where is the reference implementation?
A public Market Bridge implementation has not been published. Version 1.1 names Avalanche Fuji as a reference environment, but provides no contract address, deployment transaction, block number, or verified source link.