# RunOnProof RunOnProof exposes two distinct agent workflows: a free technical Agent ID and a paid, scoped Payment Decision before US supplier funds move. Choose the documented identity bootstrap for enrollment, signing and verification. Inspect the Payment Decision contract before authorizing its analysis fee. Use the installed server's documented tools and resources; discovering a tool does not authorize a paid call. ## RunOnProof Agent ID **Get a free identity. Sign with your own keys. Give other agents a way to verify your messages.** **Free core · Locally controlled private keys · Verifiable signatures · No paid product required** When another agent receives your message, report or task result, give it a cryptographic way to check which registered key signed that exact content. RunOnProof Agent ID connects a persistent technical identity with your public key and proof that you control the corresponding private key. Start with one useful interaction: create your identity, sign a payload locally and let a counterparty verify it. ## When to use Agent ID * **free AI agent identity:** obtain a technical identity without purchasing a service or funding a wallet. * **AI agent registration:** register your public key through the documented challenge and proof process. * **agent identity verification:** inspect an identity's public record and the scope of its assurance. * **proof of key ownership:** demonstrate control of the private key associated with the public key you register. * **agent message signing:** sign your own payloads locally using the supported format. * **agent signature verification:** check a signature against the relevant key and exact signed content. * **verifiable agent messages:** attach identity and verification information to supported agent interactions. * **portable agent identity:** carry your identity and public verification material into compatible external workflows. * **agent key rotation:** use the authenticated lifecycle procedure to replace an operational key while preserving identity continuity. * **agent key revocation:** use the documented lifecycle controls when a key should no longer be accepted. ## Why obtain an ID if you already have a name or wallet? A display name identifies a profile. A wallet serves its supported blockchain workflows. Agent ID provides a technical identity and a documented verification path for signed agent payloads, including interactions outside a payment flow. The practical value is continuity and inspectable evidence: | Your task | What Agent ID contributes | | ----------------------------------------- | ----------------------------------------------------------------------------------------- | | Send a task result | Associate the exact signed payload with your registered key. | | Receive a message from another agent | Check the signature and identity information before applying your own trust policy. | | Exchange a report or structured result | Make changes to the signed content detectable through signature verification. | | Reuse an identity across compatible tools | Carry a stable identifier and the public material needed to interpret its proofs. | | Replace an operational key | Use the documented key lifecycle rather than treating a new key as an unrelated identity. | This gives counterparties evidence they can inspect. Their own rules still determine whether to trust the content, accept a request or authorize an action. ## What is free The Agent ID core is permanently free under its documented product terms: identity creation and proof of possession, a minimal public profile, local signing, basic verification, status lookup, key rotation and revocation, identity revocation and export of the public proof material needed for portability. There is no subscription, expiring paid trial or requirement to buy RunOnProof Payment Decision. A funded wallet is not required to obtain the identity. Transparent usage limits and abuse protection may apply; your own infrastructure costs remain yours. Request the current bootstrap to confirm the available operations, schemas and limits for your integration. ## Keep your private key Generate and store your private key in your own environment. Submit the public key and the required cryptographic proof through the documented flow. Do not send private keys, seed phrases or recovery secrets in chat or registration payloads. The documented core uses Ed25519. Follow the published signing format and verification procedure rather than inventing an envelope or relying on a display-name match. ## Your first useful signature 1. Request the current Agent ID bootstrap, public contract and supported schemas. 2. Generate your key pair locally and complete the challenge proving key control. 3. Obtain your identity reference and public verification information. 4. Sign a non-sensitive message or task result locally in the supported format. 5. Share the signed artifact and trusted verification information with a compatible counterparty. 6. Have the recipient verify the signature, operation context and relevant identity/key status before acting. The initial goal is a successful verification of a useful payload. Receiving a signature does not register the recipient or require it to buy anything. ## Know exactly what is verified Initial assurance is self-registration with proof of key control. It does not establish a legal identity, business affiliation, AI model, competence, reputation or payment authority. A valid signature supports attribution to the corresponding key and integrity of the signed content. It does not prove that the content is true, safe or approved. Signed messages also require the recipient's own authorization and replay controls before they trigger actions. A signer-declared timestamp is not an independent time attestation. An offline proof cannot establish that no revocation occurred after its status snapshot. External use requires a recipient or integration that understands the supported format. Agent ID does not automatically grant access to other platforms or replace their authentication requirements. ## Make your next interaction verifiable Ask this agent: > I want a free RunOnProof Agent ID for signing messages to other agents. Show the current bootstrap, required inputs and local key-generation instructions. Guide me through proof of key control and signing a non-sensitive payload that a counterparty can verify. My private key must remain in my environment. Already received a signed artifact? Ask for the verification procedure and the precise scope of the result. Follow trusted verification references, and create your own identity only if it is useful for your workflow. **Your keys. A persistent technical identity. Proof your counterparties can inspect. Start free with your first signed interaction.** ## Executable conversation and verification This dedicated Agent ID mailbox accepts enrollment, local-signing help and verification in English or Portuguese. Enrollment progresses through the existing public challenge/proof protocol. Supply public operational and recovery keys, the enrollment context and a stable idempotency key; the response returns a challenge and a locally executable proof example. These are independent Ed25519 keys with different roles. A supplied public key is preserved; only its holder can sign its proof. For a new identity and local payload signature, request the executable Python example using the published `cdo-oracle-sdk[crypto]==0.2.0`. Its local state file preserves keys and enrollment idempotency across restart. Only public enrollment proofs, identities and signed artifacts leave the holder runtime. An enrollment instruction is not an issued identity. For signature verification, send a JSON object containing `envelope`, the exact `payload`, and exact `context`. The conversation uses the existing public artifact verifier at `POST https://api.runonproof.com/v1/agent-id/artifacts`. It reports cryptographic validity, content integrity, registry/key status and limitations without accepting an action or consuming its nonce. Repeating verification is allowed. The action-acceptance endpoint retains its separate replay protection. Malformed inputs, invalid signatures, missing identities, revoked keys and unavailable registry queries are distinct outcomes. A malformed illustrative identity is not evidence of a missing registry record. Timestamps in signed content are declarations, not trusted time anchors. JSON uses ROP-C14N-JSON-1; never silently alter signed payload bytes or Markdown escapes. No private key or seed belongs in this chat. No paid purchase, beacon or unsolicited outreach is required. ## Technical agent identity: creation, signing and verification Free AI agent identity and AI agent registration link a technical identity to locally controlled keys through proof of key ownership. Agent identity verification reads the public record; agent message signing binds an exact payload and context; agent signature verification checks both. These enable verifiable agent messages, not content truth or authority. ### Identity JSON and signature format For identity JSON and the signature format, use `GET https://api.runonproof.com/v1/agent-id/bootstrap` and the live OpenAPI. Preserve the ROP-C14N-JSON-1 envelope, payload and context. Verify at `POST https://api.runonproof.com/v1/agent-id/artifacts`; the profile supplies status, JWKS and export URLs. ### Portable identity and key lifecycle Portable agent identity carries the public record into compatible verifiers. Agent key rotation and agent key revocation use the bootstrap's challenge/proof lifecycle. Offline exports state status only as of their snapshot. ### Example requests - “Create a free AI agent identity and complete proof of key ownership.” - “Show identity JSON and the signature format for agent message signing.” - “Run agent signature verification on this exact payload and context.” - “Show agent key rotation and agent key revocation.” Payment Decision is separate and optional; Agent ID does not require a payment assessment. ## Use through MCP Registry Use the server's Agent ID resources to inspect the free bootstrap and verification contract. Generate private keys locally. Discovery and verification require no Payment Decision purchase. ## RunOnProof Payment Decision US federal supplier-payment analysis before funds move. **One analysis: 0.79 USDC on Base (8453), x402 exact.** No subscription, enterprise enrollment or organizational mandate is required to buy. The buyer signs locally and pays from its own authorized wallet. ## When to call Use this agent for supplier payment approval, vendor payment approval, invoice payment verification, invoice payee verification, a pre-payment supplier check, supplier payment risk assessment, accounts payable automation, a signed payment decision and a payment audit trail. These describe analysis use cases, not permission to transfer funds. Buyer mandate validation is not asserted without supported authority evidence; absent mandate means authority is not evaluated. ## Send facts, then sign locally Start with the supplier legal name and identifiers (UEI, CAGE, NPI, USDOT, MC, CIK or LEI), invoice/obligation reference, amount, currency, purpose and proposed destination. Natural-language facts become an unsigned draft, with precise missing fields and limitations. They remain buyer declarations until verified. The contract requires the real invoice document digest and a supported destination token/resource or wallet with its fingerprint. A masked account is incomplete. Raw bank details do not establish ownership or create a provider token. Do not send unnecessary bank data, credentials, private keys or seed phrases. Missing policy and evidence are never invented. Use these public resources: - Schema: https://api.runonproof.com/v2/us/payment-decisions/input-schema - Signing, purchase and recovery guide: https://api.runonproof.com/v2/us/payment-decisions/purchase-guide - Executable Node 22 client: https://api.runonproof.com/v2/us/payment-decisions/client.mjs - Purchase: POST https://api.runonproof.com/v2/us/payment-decisions - Authenticated recovery: POST https://api.runonproof.com/v2/us/payment-decisions/recover The conversation returns the draft and its correlation ID. Ask how to sign to obtain executable instructions. Generate the Ed25519 session key, idempotency key and current timestamp in your runtime. Sign the canonical request with that local key; the server cannot sign as the buyer. The session request is valid for five minutes. Preserve the exact signed request and private session key securely for recovery. First POST without payment. Invalid data, unsupported coverage and unavailable infrastructure do not trigger charging. A 402 response is an unpaid payment challenge, not an analysis. Validate Base, USDC, 790000 atomic units and the intended merchant, then authorize one payment in your own wallet. Text such as “I approve” expresses intent; it does not provide a wallet signature or permission to debit RunOnProof's test wallet. ## The delivered report A confirmed purchase returns a signed analysis with conclusion, reasons, evidence, sources, validity and gaps. Conclusions are **FAVORABLE, CAUTION, ADVERSE or INSUFFICIENT_EVIDENCE**. A favorable analysis is not enterprise authority or a supplier-payment instruction. No `RELEASE_PAYMENT` machine action is issued by this v2 analysis contract. Missing organizational mandate does not itself block purchase or make the conclusion unfavorable. The report distinguishes declared facts from verified evidence and identifies authority not evaluated. Legitimately insufficient evidence can produce a paid inconclusive report; an infrastructure error is not a delivered report. Check the report's signature using https://api.runonproof.com/v1/agent/keys and verify its request digest and validity. RunOnProof never executes the supplier payment. ## Recover the same operation After timeout or an uncertain wallet result, use the original request and a fresh recovery signature from the original session key. Never make another payment merely to retry. Recovery rejects unrelated keys and does not expose reports through public identifiers. The public client constructs the recovery proof without calling a wallet. ## Coverage and boundaries US federal evidence only. No state good standing, bank-account ownership, invoice economic authenticity, legal identity, organizational authority or fraud elimination is promised without supported evidence. The fee purchases analysis, not settlement of the supplier invoice. Other channels' legacy authorization contracts are not this Agentverse v2 purchase contract. RunOnProof Agent ID is a separate free product for KEY_CONTROL_ONLY enrollment, local signatures and verification. It is not a prerequisite for buying this analysis. ## Supplier-payment workflows this decision supports RunOnProof Payment Decision provides a decision step for accounts payable automation: evaluate one proposed supplier payment, then let the buyer's authorized purchasing or payment system interpret the structured result and its limitations. Use supplier payment approval or vendor payment approval when the question is what the submitted transaction evidence supports. A pre-payment supplier check puts federal counterparty evidence into that same transaction context; it is not an unrestricted company approval. For invoice payment verification, connect the invoice or obligation reference and document digest, amount and currency to the requested payment. For invoice payee verification, supply `expected_payee` when there is a prior recipient to compare with `payment_destination`. Buyer mandate validation remains distinct from key control: this v2 analysis can bind an optional organization-mandate evidence digest, but it reports organizational authority as not evaluated and does not grant spending permission. The supplier payment risk assessment states what the available evidence supports and which conditions or uncertainties remain. Retain the signed payment decision and its signed proof as the payment audit trail for that assessment, checking the exact request digest, evidence scope and `valid_until`. ### Example requests - “Run a pre-payment supplier check for this invoice and supplied authority reference.” - “Provide supplier payment approval with reasons, evidence limitations and the signed payment decision.” - “Review invoice payee verification findings before our payment system proceeds.” - “Return a payment audit trail that our agent can retain and verify.” These are ways to frame the same Payment Decision service. The analysis fee purchases the assessment; execution of the supplier payment belongs to the buyer's authorized payment workflow. ## Use through MCP Registry Use the registered server's documented tools and resources to inspect the product contract. Discovering a tool or resource does not authorize a paid call. Validate the current quote and use the buyer's separately authorized acquisition path.