Transparency Proofs

Every execution has a proof you can check offline: the API’s audit events for it, in an append-only log whose checkpoints are signed by a notary inside the attested TEE. You don’t need to trust the API operator.

At a glance

Get it: GET /v1/agents/{agent_id}/operations/{correlation_id}/proof, or api.getOperationProof() in the SDK, for any op_… execution.
Check it: verifyOperationProof(proof, "api.agentsonintents.com/log"), offline.
Then, yourself: look up the settlement transactions on-chain, and verify the notary’s TDX quote as on TEE & Attestation.

How it works: the API records every action’s audit events in an append-only Merkle log. The log’s checkpoints are signed by a notary whose keys are bound to a hardware attestation of the code that runs it. The proof endpoint returns the retained events for one execution, with proofs anyone can check.

Get and verify a proof

The call needs your partner API key. correlation_id is the op_… id of an execution of that agent. Owner intents (intent_…) have no operation proof.

import { createAgentApi, NoteError, ProofError, verifyOperationProof } from "@near-intents-agent-api/sdk";

const api = createAgentApi({ apiKey: process.env.NEAR_INTENTS_AGENT_API_KEY! });
const proof = await api.getOperationProof(agentId, correlationId);

try {
  // Pin the origin yourself. Never take it from the proof.
  const verified = verifyOperationProof(proof, "api.agentsonintents.com/log");
  for (const event of verified.proven)
    console.log(event.fields.action, event.fields.createdAt, event.evidence);
  console.log(verified.pending, verified.unlogged, verified.birthReportData);
} catch (error) {
  if (error instanceof NoteError || error instanceof ProofError) throw new Error("proof does not hold");
  throw error;
}

curl "$NEAR_INTENTS_AGENT_API_URL/v1/agents/$AGENT_ID/operations/$CORRELATION_ID/proof" \
  -H "X-API-Key: $NEAR_INTENTS_AGENT_API_KEY"

verifyOperationProof runs offline. It throws NoteError or ProofError when the proof is for another log, a signature is wrong, an event isn’t this execution’s, or a recorded result was changed after it was committed. The verify-operations example is a complete script.

Response

Field	Description
`correlation_id`	The execution the events belong to
`origin`	The log’s origin name. The hosted API’s is `api.agentsonintents.com/log`.
`notary`	The verifier keys and the birth attestation, or `null` before the first checkpoint is published
`events[]`	Every retained audit event of the execution, oldest first

Each event has an action, a created_at time, a status, a proof and its evidence:

`status`	Meaning	`proof`
`PROVEN`	The event is in a published checkpoint	A `c2sp.org/tlog-proof@v1` text
`PENDING`	The next checkpoint will cover it. Proofs use the latest checkpoint, so a recent event reads `PENDING` for a short while. Ask again later.	`null`
`UNLOGGED`	The event was recorded before the log started and was never logged	`null`

evidence is the result the event recorded, as canonical JSON, or null when it recorded none. For an execution, it includes the settlement transaction hashes. notary holds log_key and notary_key (the verifier keys), signing_address, and birth: the TDX attestation quote, its report_data, and previous, the checkpoint the notary continued from after a restart, or null on its first boot. The log’s public tiles and latest checkpoint are served at https://log.agentsonintents.com/.

What a proof lets you check

A PROVEN event’s proof carries the event’s opening (the committed content, in the extra line), its leaf index, the inclusion path and the signed checkpoint. verifyOperationProof checks, offline, that:

The notary keys belong to the origin you pinned and match the birth attestation’s report_data.
The checkpoint is signed by the log key and cosigned by the notary key.
The opening hashes to a leaf the checkpoint includes, and names this execution, its action and its time.
The evidence hashes to the opening’s evidenceHash, so a result changed after it was committed is refused.

Two more steps are yours to run:

Check the settlement on-chain. Look up each NEAR transaction the evidence names: tx_hash, transaction_hash and settlement_tx_hash, and destination_tx_hash only when the withdrawal’s chain is near. Each should be final and successful. Confidential routes other than withdrawals, and same-chain withdrawals that settle by intent hash alone, name no public transaction, so there is nothing to look up for them.
Check the attestation. Verify the TDX quote in notary.birth with a quote verifier, such as dstack-verifier, run by you or by a service you trust. TEE & Attestation shows how. Its report_data must equal verified.birthReportData. That ties the keys to the attested code.

Together, this shows that the attested code recorded the event under those terms, and that no recorded event was removed or rewritten afterwards. A proof does not replace the execution’s status, which reflects chain and provider evidence. It adds an audit record that the operator cannot quietly edit.

Retention and errors

The API keeps audit events for 90 days. Their commitments stay in the log, so the tree stays valid, but an expired event no longer appears in proofs.

Code	Status	Meaning
`operation_not_found`	404	No such execution for this agent and API key
`transparency_log_disabled`	501	This deployment does not run the transparency log

See Status & Errors for every code.

Agent API

Quickstart

Guides

Trust & Verification

API Reference

Get and verify a proof

Response

What a proof lets you check

Retention and errors

​Get and verify a proof

​Response

​What a proof lets you check

​Retention and errors

Get and verify a proof

Response

What a proof lets you check

Retention and errors