Check an AI payment proposal before funds move

When AI prepares a payment proposal, engineers need to decide up front what a machine checks and what stays with a separate system. This article reads a recorded run of the open-source Agent Role Contracts (ARC) onchain-finance checks on fictional data. It also gives the steps to reproduce the standard demos and separates what the record does not show.

Scope of the record

Netsujo, which publishes ARC, ran three programs on November 3, 2026, from 15:29:52 to 15:29:55 JST, against a pinned public commit (a2fa013, package version 1.0.0). The environment was Linux x86_64, Node.js v24.22.1 and npm 11.9.0. All three exited with code 0.

• Only fictional tokens, addresses and evidence were used. No wallet, RPC, API key, signing or broadcast was involved. No funds moved.
• The evaluation clock was fixed at January 1, 2030. That is separate from the time the programs ran.
• Numbers and codes in this article are quoted from that record. The Miyako de IT editorial team did not re-run them.

Observation 1: the standard finance demo

The standard demo checks eight scenarios in order. The key lines of its output:

Scenario 1: Treasury payment within the declared limit: PASS

Scenario 2: Proposal switches to a different chain: FAIL (expected): FINANCE_CHAIN_NOT_ALLOWED

Scenario 3: Payment exceeds the limit by one base unit: FAIL (expected): FINANCE_TRANSFER_LIMIT_EXCEEDED

Scenario 4: Agent requests an unlimited token allowance: FAIL (expected): FINANCE_UNLIMITED_APPROVAL_REFUSED

Scenario 5: Amount changes after review: FAIL (expected): FINANCE_SUBJECT_MISMATCH

Scenario 6: New fictional declarations bind the changed proposal: PASS

Scenario 7: Execution receipt matches the approved subject, chain and nonce: PASS

Scenario 8: Execution receipt uses a different nonce: FAIL (expected): FINANCE_EXECUTION_NONCE_MISMATCH

Scenarios 5 and 6 are worth reading together. In this demo, a proposal that changed after review is rejected, and it passes only once new declarations are bound to it. The approval for one proposal is shown not being reused for a later change.

Observation 2: the Safe demo and additional checks

The Safe demo confirmed that an approved finance intent matches the supported fields of one supplied Safe CALL envelope: PASS. The same output states that wallet, authorization and signatures were not verified (false false) and that canonical serialization and the transaction hash were not verified (false false).

Beyond the standard demos, Netsujo ran additional checks without modifying the policy or approval declarations:

• A1 to A3: changing the recipient to a different address gives FAIL (FINANCE_RECIPIENT_NOT_ALLOWED). Restoring the original proposal gives PASS.
• B1 to B3: changing the last calldata nibble of the Safe call from 0 to 1 gives FAIL (SAFE_DATA_MISMATCH). Restoring it gives PASS.
• C1 to C3: checking the same proposal (250000000 base units against a per-proposal limit of 500000000) three times gives PASS all three times.

Expected versus observed

• Expected: a recipient, chain, amount or calldata that differs from the declarations is rejected. Observed: within the recorded cases, each failed with the expected rejection code.
• Expected: restoring the original input returns to PASS. Observed: A3 and B3 returned to PASS. What was restored was the original proposal; the changed proposal was not approved.
• Expected (a design assumption): ARC does not count cumulative budget or duplicate execution. Observed: the same proposal passed three times. This is consistent with that assumption. Cumulative budget and replay prevention need to be carried by something such as a ledger in the execution system.

Reproduce the standard demos

The two standard demos can be reproduced from the public repository. You need Git, Node.js and npm. The package.json declares node 22.5 or later; the recorded run used v24.22.1. The record states that no dependency installation is needed; only the clone uses the network.

• git clone https://github.com/suirindo/agent-role-contracts.git
• cd agent-role-contracts
• git checkout --detach a2fa013deafb81fb973fadf1e2e1a2adb60e693e
• npm run demo:finance --silent
• npm run demo:safe --silent

Check three things: (1) the exit code is 0; (2) the finance demo prints the eight lines above, in that order and with those codes; (3) the closing lines of the finance demo carry a notice, in substance, that PASS checks declarations only and does not authorize execution (the Safe demo does not print it). The individual expected rejections appear inside a successful run. They are not process failures.

The script that ran checks A to C is not included in the public ARC repository; it exists only in Netsujo's run record. A to C are recorded observations, not checks a reader can reproduce with the same script. To test it yourself, change one input of the finance demo and compare the changed item with the rejection code that corresponds to it.

Limits and what is not verified

• The check covers consistency of declarations only. It does not verify execution authorization, signatures or real chain state. PASS does not mean the payment may be sent.
• Approval by a real person, real funds and real chain execution are not part of this record.
• Cumulative budget, replay prevention, and who supplies the policy and by what route are not covered by this record.
• The run was one environment, one time. Other operating systems, Node versions and long-term operation were not measured.

What to try next

To try the same shape in your own system, write down three things separately: the proposal the AI produces, the conditions a person approved, and the constraints the execution system holds. Then list what a declaration check like ARC can see and who owns the rest. You can start by running the two demos above and reading their output.

Related: Agent Role Contracts is now open source / Putting PASS, FAIL and PASS on one page for a public demo / Defining AI delegation in onchain finance with Agent Role Contracts (Netsujo)