# Accord

> The private deal room and control plane for agent-to-agent commerce.

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.

Source code (MIT): https://github.com/Adityaakr/accord · Machine-readable facts: https://accordweb-production.up.railway.app/facts.json · Every page as Markdown: https://accordweb-production.up.railway.app/llms-full.txt

## Status

- Network: NEAR testnet only. Mainnet follows an audit and is not live.
- Proof: agreement a6.accord-v2.testnet ran the full flow on 8 Nov 2026 on factory accord-v2.testnet, release 3: sealed limits, the Sealed Table negotiation by the real NEAR AI model inside OutLayer's attested enclave, approvals, funding, a payment, a refused redirect (ERR_PAYEE_MISMATCH) and a revocation. Each of its 12 transactions is linked at https://accordweb-production.up.railway.app/record
- Settlement: USDC on NEAR (NEP-141), from each agreement's own account; on testnet a test USDC token (tUSDC).
- Agreement types: six; two are built (vendor contracts, called procurement in code, and market-making agreements) and four are planned.
- Sign-in: external NEAR wallets only, through HOT Connect. There is no email sign-in.

## Try it (no code, about 3 minutes, NEAR testnet)

Start at https://accordweb-production.up.railway.app/app/try-it (walkthrough with screenshots: https://accordweb-production.up.railway.app/docs/quickstart). A faucet, a demo counterparty and a demo agent run by Accord are built in; everything uses test USDC.

1. **Connect a NEAR wallet.** Do: Open /app/try-it and connect a NEAR testnet wallet through HOT Connect (Meteor or Intear send through Accord's relayer, so you pay no gas). See: Step 1 marked done with your account name.
2. **Get test funds.** Do: Get test funds from the faucet (once a day per account). See: Your balance reads 2.50 NEAR and 100 tUSDC, with both faucet transactions linked.
3. **Create the deal room.** Do: Create the room, prefilled against Accord's demo vendor halcyon-demo.testnet; your wallet signs create_agreement on the factory accord-v2.testnet with a 2 NEAR deposit, returned when the room closes. See: A new agreement account such as a8.accord-v2.testnet, in state Sealed.
4. **Seal your limits.** Do: Seal the Northwind preset (40 tUSDC ceiling, 2 to 4 items); it is encrypted in your browser to the Sealed Table. See: The demo counterparty seals its own mandate and the negotiation runs; the state moves from Sealed to Attested.
5. **Approve, fund and accept.** Do: Approve the terms, fund the escrow, accept the recipient and the first delivery. See: The recipient halcyon-mm.testnet proven on the vendor's domain, approved by its authority and active once you accept it.
6. **Let the demo agent pay.** Do: Start the demo agent; your wallet signs install_agent_key, one function-call key that can call act and nothing else. See: Paid item 1 to halcyon-mm.testnet, with the act transaction linked.
7. **Try a redirect.** Do: Ask the agent to pay a new account. See: ERR_PAYEE_MISMATCH: the contract refused it, recorded the refusal and moved nothing.
8. **Revoke the key.** Do: Revoke the agent from the room header. See: Agent revoked; its next call is rejected by the network (AccessKeyDoesNotExist).
9. **Check it from public data.** Do: Open /verify and enter your agreement account (or open /verify?agreement=<account>). See: Five checks run in the browser with no account and no keys; /record shows agreement a6's 12 transactions.

## Key URLs

- [Try it](https://accordweb-production.up.railway.app/app/try-it): the guided test room on NEAR testnet, with faucet, demo counterparty and demo agent
- [Sign in](https://accordweb-production.up.railway.app/app/signin): the app, with your own NEAR wallet
- [Verify an agreement](https://accordweb-production.up.railway.app/verify): five public checks of any agreement in the browser, no account and no keys; https://accordweb-production.up.railway.app/verify?agreement=<account> opens one directly
- [Public record](https://accordweb-production.up.railway.app/record): agreement a6's 12 transactions, each linked to the explorer
- [Security](https://accordweb-production.up.railway.app/security): the claims table with every limit, custody, the privacy boundary and the threat model
- [Documentation](https://accordweb-production.up.railway.app/docs): The docs overview: what Accord is, and every docs page by section.
- [Docs: Quickstart](https://accordweb-production.up.railway.app/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](https://accordweb-production.up.railway.app/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](https://accordweb-production.up.railway.app/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](https://accordweb-production.up.railway.app/docs/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](https://accordweb-production.up.railway.app/docs/verify): 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](https://accordweb-production.up.railway.app/docs/cli): 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](https://accordweb-production.up.railway.app/docs/contracts): 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](https://accordweb-production.up.railway.app/docs/security): 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](https://accordweb-production.up.railway.app/docs/references): The official documentation behind each part of Accord, the NEAR standards it uses, and the primary sources for the problem it addresses.

## Testnet accounts

- Factory (release 3): [accord-v2.testnet](https://testnet.nearblocks.io/address/accord-v2.testnet)
- Agreement that ran the full flow on 8 Nov 2026: [a6.accord-v2.testnet](https://testnet.nearblocks.io/address/a6.accord-v2.testnet)
- Test USDC (tUSDC, NEP-141, 6 decimals): [tusdc.accord-v1.testnet](https://testnet.nearblocks.io/address/tusdc.accord-v1.testnet)
- Relayer: [relay.accord-v2.testnet](https://testnet.nearblocks.io/address/relay.accord-v2.testnet)
- OutLayer: [outlayer.testnet](https://testnet.nearblocks.io/address/outlayer.testnet)
- Demo vendor (Accord's own account): [halcyon-demo.testnet](https://testnet.nearblocks.io/address/halcyon-demo.testnet)
- Demo vendor's settlement authority: [halcyon-auth.testnet](https://testnet.nearblocks.io/address/halcyon-auth.testnet)
- Demo vendor's authorised recipient: [halcyon-mm.testnet](https://testnet.nearblocks.io/address/halcyon-mm.testnet)
- OutLayer jobs: accord-v1.testnet/accord-sealed-table, accord-v1.testnet/accord-payee, accord-v1.testnet/accord-observer

## Accord for AI agents

An agent never holds a wallet: the buyer installs one function-call key on the agreement's own account that can call `act` and nothing else, and the contract checks every payment against the approved terms. The code is at https://github.com/Adityaakr/accord (packages: https://github.com/Adityaakr/accord/tree/main/platform/packages). Ways in:

- **Source**: Clone https://github.com/Adityaakr/accord (MIT) and run pnpm install in platform/. Read-only check of the testnet agreement, no keys: ACCORD_FACTORY=accord-v2.testnet make verify DEAL=a6.accord-v2.testnet (it prints verify: <n> checks ok). The MCP server, SDK and CLI live in platform/packages; methods, tools and commands are specified in platform/INTERFACES.md.
- **MCP server (@accord/mcp)**: pnpm --filter @accord/mcp dev from platform/ with ACCORD_FACTORY=accord-v2.testnet; stdio by default, or streamable HTTP at /mcp with --http <port>. Read tools need no key: accord_list_agreements, accord_get_agreement, accord_due_items, accord_preflight, accord_refusals, accord_receipts, accord_verify. accord_pay and accord_request_exception need the agent's function-call key (ACCORD_AGENT_KEY with AGENT_AGREEMENT); accord_pay runs preflight first and the contract checks again. Principal tools (accord_seal_mandate, accord_approve_terms, accord_submit_delivery, accord_propose_recipient) are off unless ACCORD_PRINCIPAL_KEY and ACCORD_PRINCIPAL_ACCOUNT are set; a key is never a tool argument.
- **SDK (@accord/sdk)**: TypeScript on near-api-js: agreements, sealing a mandate, the agent's act, preflight and verify.
- **CLI (accord)**: Every step of an agreement from a terminal (create, seal, negotiate, approve, fund, recipient, deliver, pay, agent revoke, verify and more); read-only commands (show, refusals, receipts, check, verify, watch) need no key. Run it with pnpm --filter @accord/cli dev -- <command>; make verify DEAL=<account> checks any agreement from public data.
- **Without code**: Read /llms.txt, /facts.json, or any page as Markdown (add .md to its path, or send Accept: text/markdown). /verify?agreement=<account> checks an agreement in the browser; testnet.nearblocks.io shows every transaction.

## Claims and their limits

Every public statement about Accord is one of these six, each with its limit. The full table is at https://accordweb-production.up.railway.app/security

1. **Each company's mandate is readable only inside attested enclaves.** Limit: Under the hardware's trust assumptions (Intel TDX, NVIDIA confidential computing) and OutLayer's keystore governance. The deployer owns the seed and the factory account and could rebind the seed to another build. Prompts reach the model through NEAR AI's attested gateway over TLS. The browser trusts the code the app serves; the CLI is the alternative.
2. **The approved terms are the agent's only authority.** Limit: The agent's judgement is bounded, not protected: it can still be fooled into asking. Attestation proves which code produced the terms, not that the deal was good; people decide that when they approve.
3. **Payments go only to the authorised recipient.** Limit: Authorisation proves control of the domain and the settlement authority's approval, not that the company legally exists. A legal KYB check is a later integration.
4. **Revoking ends the agent's authority in one transaction.** Limit: A payment already made stays made. A call that reached the chain before the revoke still runs, with every check. Revoking never cancels what the vendor has earned.
5. **Negotiation is private; settlement is public.** Limit: The enforced schedule (amounts, dates, recipient) and every payment are public on NEAR, as with any stablecoin payment.
6. **A market-making agreement's payment becomes eligible only when the agreed observations pass, unless the buyer approves an exception.** Limit: The observer measures the venue's liquidity, not the market maker's own orders. The deployer owns the observer's seed. A slot nobody polls in time counts as unobserved, and an undecided period goes to the buyer, not to payment.

## Not done yet

- Mainnet: Accord runs on NEAR testnet only; mainnet follows an audit.
- Market making on testnet: it runs end to end on a local node reading real NEAR mainnet blocks; on testnet it waits on an OutLayer payment key, and no market-making observation is recorded on testnet yet.
- Four agreement types are planned, not built: agent-to-agent services, security remediation, infrastructure service agreements, and grants and funded milestones.
- Funding an agreement from other chains through NEAR Intents is planned.
- A legal KYB check of the vendor is a later integration; Payee proves domain control and the authority's approval only.
- Verifying a market maker's own contribution with its authenticated account data is planned.
- The SDK, MCP server and CLI are not published to npm; they run from a clone of the repository (https://github.com/Adityaakr/accord), under platform/packages.
- Production prices are published before launch; testnet use is free with test funds.

## Agreement types

Same controls in every type; the commercial fields and the evidence accepted change. "demo": built and run in the demonstration. "planned": designed, not built.

- **Market-making agreements** (demo): Pay a market maker for liquidity that showed up. A retainer is paid for a period only if enough observations of the venue's public liquidity, taken at hidden times inside an agreed schedule, meet the agreed spread, depth and two-sided quoting. In the demonstration, 4 of 6 readings of Rhea's USDC/wNEAR pool must pass. Evidence: Attested observations of the pool's public liquidity. Limit: Public order-book observations measure the venue's liquidity, not the hired market maker's own contribution. Verification with the market maker's authenticated account data is planned. Its recorded runs are on a local node reading real NEAR mainnet blocks; no market-making observation is recorded on NEAR testnet yet.
- **Vendor contracts and renewals** (demo): Let an agent pay invoices it cannot redirect. Invoices clear against approved milestones once delivery is accepted. A message asking the agent to pay a new account is refused by the contract (ERR_PAYEE_MISMATCH), whatever the agent was told. Evidence: Buyer acceptance of delivery; the recipient bound to the vendor's domain through Payee.
- **Agent-to-agent services** (planned): Buy a service from another company's agent within a weekly amount and a total cap. Price agreed agent to agent in the Sealed Table; each period becomes payable on schedule; anything over the weekly amount or the cap is refused; the buyer can revoke the agent's key in one transaction. Evidence: Schedule and cap in the approved terms.
- **Security remediation** (planned): Pay for a security fix only when the checks pass. The researcher's fee is agreed before work starts and stays in escrow until the agreed regression checks pass on the patch and the named reviewer approves it. Evidence: Agreed checks passing on the patch, plus the named reviewer's approval.
- **Infrastructure service agreements** (planned): Hold a month of capacity that missed its service levels. Monthly capacity pays in full when availability and latency meet the agreed levels; a shortfall follows the agreed rule, and the provider can dispute the reading. Evidence: The agreed monitor's availability and latency readings.
- **Grants and funded milestones** (planned): Release a grant when the reviewers sign off. Each tranche moves only when two of three named reviewers accept the milestone, and only to the account the grantee has proven it controls. Evidence: Reviewer acceptance (2 of 3) of each milestone report.

## How a deal room works (six steps)

1. **Sealed**: Each company sets its limits in the browser and seals them; a mandate is encrypted to a key that exists only inside the Sealed Table's enclave. On NEAR: the ciphertext and its commitment hash.
2. **Attested**: Both companies' agents negotiate inside the Sealed Table; code checks every proposal against both mandates' hard limits, and only the agreed terms come out, with an attestation.
3. **Approved**: People at both companies approve the terms; Payee binds the recipient (domain proof, settlement authority, buyer acceptance); the buyer funds the agreement's USDC escrow on NEAR.
4. **Executing**: The buyer's agent holds one key that can call one method, act; a payment must match the approved milestone, amount and recipient, or it is refused and recorded (for example ERR_PAYEE_MISMATCH).
5. **Checked**: A payment becomes eligible only when the agreed evidence is recorded: observations at hidden times, delivery acceptance or a named reviewer's approval; otherwise it is withheld for review.
6. **Settled**: Eligible payments complete to the authorised recipient in USDC; the buyer decides exceptions and can revoke the agent's key in one transaction; the record stays checkable with make verify.

## Core features (seven controls)

- **Confidential negotiation**: Limits are sealed in the browser and agents negotiate inside an attested enclave; only the agreed terms and an attestation come out.
- **One key, one method**: The buyer's agent holds a FunctionCall key that can call act on one contract and nothing else.
- **Every payment checked**: Each payment must match the approved milestone, amount and recipient; anything else is refused with a recorded reason.
- **A recipient that cannot be redirected**: The vendor proves its domain, its settlement authority approves the account and the buyer accepts it; a message cannot change it.
- **Evidence before release**: A payment becomes eligible only when the agreed evidence is recorded; otherwise it is withheld.
- **Stop the agent in one transaction**: revoke_agent deletes the agent's key; later calls fail with AccessKeyDoesNotExist; payments already made stay paid.
- **Checkable from public data**: make verify checks the contract code, the agent key, the recipient proof and the record with no keys; the release attestation check needs the outlayer-verify tool.

## Built on

- **NEAR**: The agreement contract, its escrowed USDC and the on-chain record of every payment and refusal.
- **NEAR AI Cloud**: Private inference for the negotiating agents; each response's signature is checked in the enclave.
- **OutLayer**: Attested enclaves for the Sealed Table, the recipient binding and the market observer.
- **USDC on NEAR**: Settlement as a NEP-141 token, paid only by the contract from each agreement's own account.
- **NEAR Intents**: Planned: funding an agreement from other chains through the 1Click API.
- **Rhea**: The USDC/wNEAR pool the market-making observer reads at hidden times.
No partnership with these projects is claimed.

## Pricing

Free on NEAR testnet with test funds today. Planned: Accord Teams, a subscription; market-making agreements, per monitored market. No percentage-based Accord fee on payment amounts. Production prices are published before launch; network and third-party fees may apply.

## Glossary

- **Deal room**: One agreement between two companies in Accord: the confidential negotiation, both approvals, the escrowed USDC, every payment and refusal, and the record.
- **Mandate**: A company's limits for a negotiation (for example a price ceiling). It is encrypted in the browser and readable only inside attested enclaves; only a commitment hash goes on NEAR.
- **Sealed Table**: Accord's confidential negotiation: both companies' agents bargain inside an attested enclave (an OutLayer job, with negotiators on NEAR AI Cloud's private inference). Only the agreed terms and an attestation come out.
- **Attestation**: Evidence, checkable by anyone, that the negotiation or observation ran in the expected enclave code. The Verify page walks the chain step by step.
- **Agreement controls**: The NEAR contract that holds the approved terms and checks every payment against them. The buyer's agent holds one key that can call one method, `act`; any payment off the terms is refused with a recorded reason.
- **Payee**: Recipient authorisation: the vendor proves control of its domain, its settlement authority approves the destination, and the buyer accepts the binding for the agreement. Payments go only to that recipient.
- **Evidence checks**: A payment becomes eligible only when the agreed evidence or acceptance is recorded, such as passing observations, delivery acceptance or reviewer approval.
- **Observation slot**: In a market-making agreement, a hidden time inside the agreed schedule at which the venue's public liquidity is read and checked against the agreed spread, depth and two-sided quoting.
- **Revocation**: The buyer calls `revoke_agent`, which deletes the agent's key in one transaction, so the agent can make no further payments. Accord does not reverse a payment already made.
- **Refusal code**: The recorded reason the contract refused a payment, for example ERR_PAYEE_MISMATCH (not the approved recipient), ERR_AMOUNT_MISMATCH (not the approved amount), ERR_ALREADY_PAID (milestone already paid), ERR_PERIOD_WITHHELD (the period's evidence did not pass), ERR_CAP_EXCEEDED (over the agreed cap) or ERR_REVOKED (the agent's key was revoked).

## FAQ

- **What is Accord?** Accord is the private deal room and control plane for agent-to-agent commerce: agents negotiate privately, both companies approve the terms, and a NEAR contract enforces who can authorise payments, who can receive them, how much can be paid and what evidence is required.
- **How does Accord stop an AI agent from paying the wrong account?** The agent cannot change the recipient. Payee binds the recipient to a domain the vendor controls and the buyer accepted, and the Agreement controls contract refuses any payment to another account with ERR_PAYEE_MISMATCH, whatever the agent was instructed.
- **Can the other company see my price limit?** No. Each company's mandate is encrypted in the browser and readable only inside the attested enclave where the agents negotiate. Only the agreed terms and an attestation come out; only a commitment hash of each mandate goes on NEAR.
- **What blockchain and currency does Accord use?** NEAR. Payments settle in USDC on NEAR (NEP-141) from each agreement's own account. Accord is deployed on NEAR testnet, where the full flow has run end to end; mainnet follows an audit.
- **What kinds of agreements does Accord support?** Six agreement types share the same controls: market-making agreements and vendor contracts (in the demonstration), and agent-to-agent services, security remediation, infrastructure service agreements and grants (planned).
- **How are market makers paid in Accord?** A retainer period is paid only if enough observations of the venue's public liquidity, taken at hidden times, meet the agreed spread, depth and two-sided quoting. Otherwise the payment is withheld for both parties to review.
- **What happens if an agent is compromised?** Its instructions can change, but its payment authority cannot: every payment must match the approved milestone, amount and recipient or it is refused and recorded. The buyer can revoke the agent's key in one transaction.
- **How do I test Accord myself?** Open /app/try-it and follow five steps: connect a NEAR testnet wallet (Meteor or Intear), get 2.5 testnet NEAR and 100 test USDC from the faucet, open a deal room against Accord's demo vendor (halcyon-demo.testnet), seal your limits (40 tUSDC ceiling, 2 to 4 items), then watch the demo counterparty negotiate in the Sealed Table, approve and deliver while you approve, fund and accept. A demo agent run by Accord for the test room pays the due item to the proven recipient, the contract refuses a payment to a new account with ERR_PAYEE_MISMATCH, and you revoke the agent key. Everything is on NEAR testnet with test USDC.
- **Is Accord live?** On NEAR testnet, yes. Accord is deployed there (factory accord-v2.testnet, release 3). The full flow ran there on agreement a6.accord-v2.testnet: sealed limits, the Sealed Table negotiation by the real NEAR AI model inside OutLayer's attested enclave, approvals, funding, a payment, a refused redirect (ERR_PAYEE_MISMATCH) and a revocation. Settlement on testnet uses a test USDC token. Mainnet follows an audit.
- **How does a deal room work?** In six steps: each company seals its limits; the agents negotiate inside an attested enclave and only the agreed terms come out; both companies approve, the recipient is bound and the buyer funds a USDC escrow; the agent pays through one method, act, and anything off the terms is refused; the agreed evidence decides whether each payment is eligible; eligible payments settle to the approved recipient and the record stays checkable.
- **How is Accord different from a wallet spending limit or an allowlist?** The limits come from a negotiated agreement both companies approved, not from a setting one side controls. The terms (items, amounts, evidence and recipient) are fixed in the agreement's own NEAR account, the agent's only key can call one method, act, and the recipient is bound to the vendor's domain, approved by its settlement authority and accepted by the buyer. Limit: Accord bounds what the agent can pay; it does not make the agent's judgement better.
- **What is private and what is public?** Private: each company's mandate (its limits) and the negotiation transcript stay inside attested enclaves; the commercial terms document is encrypted to the two parties. Public: the enforced schedule (amounts, dates, recipient), every payment and every refusal are on NEAR, as with any stablecoin payment. Limit: privacy rests on the enclave hardware (Intel TDX, NVIDIA confidential computing), OutLayer's keystore governance and the deployer never rebinding the seed to another build.
- **What stops a fooled agent from paying the wrong account?** The contract, not the agent. Every act call must match the approved item, amount, evidence and recipient; a payment to any other account is refused with ERR_PAYEE_MISMATCH and recorded, and a changed amount with ERR_AMOUNT_MISMATCH. Agreement a6.accord-v2.testnet recorded such a refusal on testnet. Limit: the agent can still be fooled into asking; a payment inside the terms goes through.
- **Which wallets can I sign in with?** External NEAR wallets only, through HOT Connect: Meteor, Intear, Ledger, Nightly or WalletConnect, switched to testnet. Meteor and Intear send through Accord's relayer, so you pay no gas. There is no email sign-in, and Accord never holds your wallet's keys.
- **What is not done yet?** Mainnet (it follows an audit), market-making observations on testnet (market making runs end to end on a local node reading real NEAR mainnet blocks; on testnet it waits on an OutLayer payment key), the four planned agreement types, funding from other chains through NEAR Intents, a legal KYB check, and verification with a market maker's own account data.
- **What is Accord built on?** NEAR (the agreement contract, escrow and record), NEAR AI Cloud (private inference for the negotiating agents), OutLayer (attested enclaves), USDC on NEAR (settlement) and Rhea (the pool the market-making observer reads). Funding from other chains through NEAR Intents is planned. No partnership is claimed.

## Naming and scope

- Accord is one product. Market-making agreements are one of its six agreement types, not a separate product; old links to /atlas redirect to /use-cases/market-making.
- Sealed Table, Agreement controls, Payee and Evidence checks are parts of Accord, not separate products.
- Accord is not a wallet or an exchange. Agreement funds are USDC in the agreement's own NEAR account, whose code is pinned by hash and has no full-access key; only the contract can send it, and only through `act`.
- Accord does not verify that a company legally exists, prove a negotiation was fair, or prove external data is true; see /security for each limit.

## How to describe Accord

- In one sentence: Accord is the private deal room and control plane for agent-to-agent commerce: agents negotiate privately, both companies approve the terms, and a NEAR contract enforces who can authorise payments, who can receive them, how much can be paid and what evidence is required.
- Status: NEAR testnet: factory accord-v2.testnet, release 3; the full flow ran on agreement a6.accord-v2.testnet (https://testnet.nearblocks.io/address/a6.accord-v2.testnet); settlement USDC on NEAR (NEP-141), from each agreement's own account; mainnet: follows an audit; not live. Testnet. Start at /app/try-it; the app opens with your own NEAR wallet; settlement on testnet uses a test USDC token.
- Say "demo" or "planned" for each agreement type as listed above. Do not describe Accord as live on mainnet, and do not attribute a market maker's own performance to public order-book observations.
- Machine-readable facts: https://accordweb-production.up.railway.app/facts.json (the same facts as fields)
- Any page as Markdown: add .md to its path (for example https://accordweb-production.up.railway.app/product/payee.md), or send `Accept: text/markdown` to the page's own URL.

## Product

- [Home](https://accordweb-production.up.railway.app/home.md): 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](https://accordweb-production.up.railway.app/market-making.md): Retainers tied to agreed liquidity conditions; scheduled observations decide whether each payment is eligible.
- [Product](https://accordweb-production.up.railway.app/product.md): Negotiation, approval and payment in one deal room.
- [Sealed Table](https://accordweb-production.up.railway.app/sealed-table.md): Confidential negotiation between agents inside an attested enclave.
- [Payee](https://accordweb-production.up.railway.app/payee.md): Recipient authorisation: domain proof, settlement authority approval and buyer acceptance.
- [Security](https://accordweb-production.up.railway.app/security.md): Claims and their limits, custody per piece, the privacy boundary and where each attack stops.

## Documentation

- [Documentation](https://accordweb-production.up.railway.app/docs.md): The docs overview: what Accord is, and every docs page by section.
- [Docs: Quickstart](https://accordweb-production.up.railway.app/docs-quickstart.md): 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](https://accordweb-production.up.railway.app/docs-concepts.md): 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](https://accordweb-production.up.railway.app/docs-agreement-types.md): 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](https://accordweb-production.up.railway.app/docs-near.md): 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](https://accordweb-production.up.railway.app/docs-verify.md): 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](https://accordweb-production.up.railway.app/docs-cli.md): 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](https://accordweb-production.up.railway.app/docs-contracts.md): 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](https://accordweb-production.up.railway.app/docs-security.md): 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](https://accordweb-production.up.railway.app/docs-references.md): The official documentation behind each part of Accord, the NEAR standards it uses, and the primary sources for the problem it addresses.

## Evidence

- [Research](https://accordweb-production.up.railway.app/research.md): Every source behind Accord's design: what each establishes, what it does not, and the decision it informs.
- [Verify an agreement](https://accordweb-production.up.railway.app/verify.md): Walk the attestation chain of an agreement, step by step.
- [Public record](https://accordweb-production.up.railway.app/record.md): Agreements, payments and refusals from the Accord demonstration, each refusal with its recorded reason.

## Optional

- [Try to move the money](https://accordweb-production.up.railway.app/try.md): The open demonstration inbox: send the agent an attack and watch the contract refuse it.
- [How to start](https://accordweb-production.up.railway.app/join.md): Sign in with a NEAR wallet, choose a workspace, create a deal room and invite the counterparty, on NEAR testnet.
- [Contact](https://accordweb-production.up.railway.app/contact.md): Get in touch with the Accord team.
- [Privacy](https://accordweb-production.up.railway.app/privacy-policy.md): What this site stores and for how long.

## Full text

- [llms-full.txt](https://accordweb-production.up.railway.app/llms-full.txt): every page as Markdown in one file