Inside Accord · Payee
Make the recipient part of the agreement.
A payment needs an approved destination as well as an approved amount. Payee connects the recipient's domain proof, settlement authority and payment address to the deal.
Set up your recipient profile Inspect a recipient record
Illustrative: A recipient bound to the vendor's domain, approved and accepted.
Establish the destination.
The vendor proposes a destination and demonstrates control of its domain. Its settlement authority approves the destination. The buyer accepts the binding for the agreement.
Treat a change as a new decision.
A new address follows the configured approval and delay process. An instruction in an email is not enough to update the bound destination.
Illustrative: A recipient change that needs a fresh proof, the authority, the buyer and a 24-hour delay.
Illustrative: The recipient's version history, including a change request that was refused.
Keep the history visible.
Inspect the current recipient version, the approvals behind it and any pending change before authorizing a payment.
Control is not corporate identity.
Domain proof establishes control of a domain. Destination approval establishes authorization within the configured process. Neither alone proves that a business exists or that its commercial claims are genuine.
Illustrative: What a payee binding proves, and what it does not.
Review recipient controls
Pages Home : What Accord is and what it is built on, the six agreement types, market-making agreements, how a deal room works in six steps, the seven core controls, use cases, why now, the demonstration, privacy, research and FAQ.Market-making agreements : Retainers tied to agreed liquidity conditions; scheduled observations decide whether each payment is eligible.Product : Negotiation, approval and payment in one deal room.Sealed Table : Confidential negotiation between agents inside an attested enclave.Payee : Recipient authorisation: domain proof, settlement authority approval and buyer acceptance.Security : Claims and their limits, custody per piece, the privacy boundary and where each attack stops.Research : Every source behind Accord's design: what each establishes, what it does not, and the decision it informs.Documentation : The docs overview: what Accord is, and every docs page by section.Docs: Quickstart : Run one deal on NEAR testnet at /app/try-it in about 3 minutes: sign in, get test funds, seal your limits, let the demo agent pay, watch a redirect get refused, and revoke the key.Docs: Concepts : The agreement's states, the parts of Accord, the agent's one scoped key, and the refusal codes the contract records instead of panicking.Docs: Agreement types : Six agreement types share the same controls; the commercial fields and the evidence accepted change. Two are built and shown in the demonstration, four are planned.Docs: How it works on NEAR : The factory and agreement contracts, the three OutLayer enclave jobs, NEAR AI Cloud's attestations, USDC held by each agreement's own account, and the relayer that never carries act.Docs: Verify an agreement : Check any Accord agreement from public data with one command and no keys, or run five of the checks in the browser at /verify.Docs: CLI and commands : Every make target a reader runs, what it does, the transaction where agreement a6 ran it on testnet, and real output from the platform README.Docs: Contracts and endpoints : The accounts and endpoints Accord uses on NEAR testnet, and the agreement contract's change and view methods, one line each.Docs: Security and limits : The six claims Accord makes, each with its limit, what NEAR does not do here yet, the limits of this testnet deployment, and the threat model.Docs: References : The official documentation behind each part of Accord, the NEAR standards it uses, and the primary sources for the problem it addresses.Verify an agreement : Walk the attestation chain of an agreement, step by step.Try to move the money : The open demonstration inbox: send the agent an attack and watch the contract refuse it.How to start : Sign in with a NEAR wallet, choose a workspace, create a deal room and invite the counterparty, on NEAR testnet.Public record : Agreements, payments and refusals from the Accord demonstration, each refusal with its recorded reason.Contact : Get in touch with the Accord team.Privacy : What this site stores and for how long.
Accord is the private deal room and control plane for agent-to-agent commerce on NEAR. It turns private negotiations into enforceable payment rules. Two companies' agents negotiate in confidence inside an attested enclave (the Sealed Table); both companies approve the terms; from then on those terms are the only authority the buyer's agent has over money. A NEAR contract (Agreement controls) refuses any payment whose amount, milestone or recipient differs from the approved terms, and Payee binds the recipient to a domain the vendor controls. Settlement is USDC on NEAR. Agreement types (market making, security remediation, infrastructure services, agent-to-agent services, vendor contracts and grants) change the commercial fields and the evidence accepted, not the controls. Two types are built: vendor contracts, which ran end to end on NEAR testnet (agreement a6.accord-v2.testnet), and the featured market-making agreement, a retainer paid only for periods where enough observations of the venue's public liquidity, taken at hidden times, met the agreed spread, depth and two-sided quoting (run end to end on a local node reading real NEAR mainnet blocks; not yet on testnet). The other four are planned. Accord runs on NEAR testnet only; mainnet follows an audit.
Live on NEAR testnet (factory accord-v2.testnet); the full flow ran on agreement a6.accord-v2.testnet; mainnet follows an audit. llms.txt · Sitemap · GitHub