The Solana implementation of the Agentic Risk Standard.

The artefacts

The mapping (six of the eight SettlementLayer methods)

Six of the eight ABC methods map to instructions already live on the Telaro Anchor program. The two fee-track methods are intentionally deferred in v1. Telaro is a capital-risk layer, and adding a generic service-fee escrow would broaden scope without sharpening the risk story.

The same mapping is pinned in code at src/settlement.ts as TELARO_SETTLEMENT_MAP, so this table and the runtime cannot drift.

The design choice we'd flag

The AP2 implementation, as we read it, fills the pay_premium recipient (the underwriter) with a designated keyholder. Since the ABC only treats the underwriter as an address, Telaro points it at a program-controlled UnderwriterPool: a permissionless USDC pool backed by an insurance reserve. The role is protocol-enforced rather than single-party. This is an implementation choice within the existing contract, not a spec change.

Install and use

The package is published. The 10-second look at the event-sourced job:

npm install @telaro/ars-solana

import { applyEvent, replay, type ArsEvent } from "@telaro/ars-solana";

const events: ArsEvent[] = [/* from your store or the chain */];
const job = replay(events);

console.log(job.state);      // e.g. "RELEASABLE"
console.log(job.collateral); // standing bond exposure for this job

replay is pure. The log is the state.

Agent Registry bridge

Telaro publishes its bond, slash, and score signals to the Solana ERC-8004 Agent Registry via the permissionless give_feedback instruction. The bridge is shipped as a separate npm package so Agent Registry consumers do not need to integrate Telaro directly: they read reputation attestations from the registry the way they would any other writer.

Bond standing posts as a positive i128 value; slashes post as the same value, signed negative; the Telaro 0..1000 score compresses into the registry's 0..100 byte. A consumer summing the values gets a net lifetime bond minus lifetime slash number per agent.

Open questions for upstream

We have opened a public design thread on the upstream repo to align on four points before formalising the contribution:

1. 1Upstream as concrete/, or external reference from the ARS repo.
2. 2Principal-track-first acceptable, with fee track following.
3. 3On-chain Anchor event source vs the reference signed-SQLite log.
4. 4Interface stability expectation on abstract_ars/ we should design against.

The thread is at t54-labs/AgenticRiskStandard#2. The artefact ships and works without the upstream answer; the questions are for alignment, not for permission.