SettledDEMO MODE

NEAR testnet demo. 1Click is MOCK.

A retry through Settled never pays twice.

Agents retry on timeouts. A cross-chain payment through NEAR Intents 1Click has no answer at pay time, so a retry can pay again. Settled is a NEAR contract the payment goes through: a repeated key is refused and refunded in the same transaction, and the payer keeps an on-chain record of the outcome.

Payer20USDC
No. 0001invoice-44172 USDC
Base0USDC

Stub No. 0001, key invoice-4417, not used yet.

Illustration of the recorded testnet run: 2 test USDC, key invoice-4417.

Open the receiptWatch the recorded runSee every outcome

What it does not do

It does not stop an agent that holds a full-access key from sending tokens straight to a deposit address. It does not reach payers whose funds sit on Base or another origin chain. The quote hash is recorded, not verified on chain. The outcome record is as trustworthy as the watcher key that writes it.

The same timeout, two endings.

Without a shared record

  1. 1The agent pays 2 USDC. 1Click has no answer yet.
  2. 2Timeout. The agent retries.
  3. 3A second 2 USDC is sent.
Paid out to Base4 USDC

Through Settled

  1. 1The agent pays 2 USDC. Record #1 is written first.
  2. 2Timeout. The agent retries with the same key.
  3. 3Refused: DUPLICATE_KEY. The 2 USDC comes back in the same transaction chain.
Paid out to Base2 USDC

Illustration. The right-hand ending is what the recorded testnet run did.

How a payment goes through.

  1. Quote, checked

    The CLI asks 1Click for a quote with refundTo set to the payer, checks the refund address, assets, recipient, amount and deadline, and stores the quote.

  2. Recorded before money moves

    The contract checks the message, the token, the key and the deadline. A new key is written to the record before any tokens move.

  3. Forwarded once

    The contract forwards the tokens to the deposit address with a memo naming the payer. A repeated key is refused and the full amount goes back.

  4. Written down for good

    A separate watcher maps 1Click's status to an outcome and writes it once. The receipt page reads it straight from the chain.

Small parts, each doing one thing.

Keys belong to a payer

Records are keyed by payer and key, so two payers can both use invoice-4417 without colliding.

Refused, not failed

A repeat returns the full amount as unused, so the token contract refunds it and the refusal is counted.

Outcomes are written once

A separate watcher key calls resolve. SETTLED, REFUNDED and FAILED_NO_REFUND cannot be overwritten.

Agents get a plain answer

Over MCP, settled_pay on a used key answers without calling 1Click.

Receipts anyone can check

The receipt page reads get_record from a NEAR RPC and reads it again when you press Verify.

The site only reads the chain

This site never calls 1Click and never holds a payer key. The paid tier we are testing would read the chain only.

Try to pay twice.

This runs in your browser with the contract's rule for keys. Nothing is sent anywhere.

No. ----no payment yet
Paid out
0 USDC
Returned to you
0 USDC
  1. Attempts show up here, newest first.

What we can count.

16contract sandbox tests pass
5contract unit tests pass
53TypeScript tests pass
60of 60 browser test runs passed

Live from the testnet contract

Limits, stated plainly.

Does Settled stop an agent that holds a full-access key?

No. An agent with a full-access key can call ft_transfer straight to a deposit address. Settled covers retries that go through the contract. Locked mode, which would close this, is planned and not built.

Does it work for payers whose funds are on Base?

No. Those payers deposit on their own chain, where the Settled contract cannot be the sender. Base-origin payers through Chain Signatures are planned, not built.

Is 1Click real in this demo?

No. 1Click has no testnet, so the testnet run uses a MOCK 1Click, and every line it prints starts with MOCK. The contract calls, token transfers, the refusal and the records are real testnet transactions. Whether 1Click accepts a deposit sent by a contract is untested.

Who decides that a payment settled?

A watcher account set by the owner. It maps 1Click's status to an outcome and writes it once. The record is as trustworthy as that key; the key cannot move funds.

Is the quote verified on chain?

No. The contract stores a hash of 1Click's signature and quote, so the payer can later show which quote it paid against.

What if 1Click fails a payment and refunds nothing?

Settled records FAILED_NO_REFUND. It cannot get the money back. See every outcome.

Pricing

Hypothesis. Not charging.

The contract, SDK, CLI, MCP server and watcher are free and open source. A paid tier we are testing would only read the chain: hosted receipt pages, webhooks fired from on-chain outcomes, and a finance export. It would never call 1Click for anyone.

Figures under test: USD 99 per team per month, or USD 0.01 per tracked payment. Nobody pays this today.

No. 0002

Read the record yourself.

The receipt for key invoice-4417 is on NEAR testnet. Open it, press Verify, and the page reads it again from the chain.

Open the receiptWatch the recorded runRead the repo