Use case · Market-making agreements

Put liquidity conditions into the payment decision.

Agree on the market conditions to measure, inspect the observations, and apply the results to the payment rules in the deal room.

Explore an example agreement Try a deal

Illustrative: The liquidity conditions both sides approved before the engagement.

Define the measurement before the engagement.

Specify the venue, the maximum spread, the minimum depth within the agreed band, whether both sides must be quoted, the number of observation slots and how many must pass for a period to pay.

Give each observation a place in the record.

Follow the measurement window, source, result and associated execution evidence. Review gaps and exceptions alongside successful observations.

Illustrative: One observation slot: the pool's public liquidity, read at a time drawn inside the observer's enclave.

Illustrative: A period decision: five of six slots passed, so the retainer is eligible.

Connect the result to the agreement.

Where the approved measurement and release rules are satisfied, the payment becomes eligible for authorization. Where they are not, the room shows what is outstanding and which review process applies.

What the current version measures.

The observer reads the venue's public liquidity, today Rhea's USDC/wNEAR pool, at times drawn inside the observer's enclave. It measures venue-level liquidity, not the market maker's individual contribution, and does not detect all forms of manipulation, guarantee execution quality or verify legal compliance.

Verification using the market maker's authenticated account data is planned. The hidden times rest on the operator never moving the observer's seed to a build that reveals them. Token loans and option-based compensation are outside the current retainer-focused flow.

Illustrative: What the current version of a market-making agreement measures, and what is planned.

Measurement record

Inspect the evidence

Review the observed spread, depth and availability for each measurement window, alongside the result produced by the agreed rules.

The evidence chain

01 Approved conditions The venue, maximum spread, minimum depth, two-sided quoting, slots per period and how many must pass, approved by both companies.
02 Observation slot One reading of the venue's public liquidity, at a time drawn inside the observer's enclave.
03 Attestation Each observation is signed by the observer's enclave and checked by the agreement before it is recorded.
04 Period decision When the approved measurement and release rules are satisfied, the period's payment becomes eligible.
05 Payment on NEAR USDC from the agreement's own account to the authorised recipient, or a refusal on the record.

Observations

No market-making observations are recorded on NEAR testnet yet.

Inspect the testnet record

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.