Idios

Idios

Private escrow and settlement for AI and other compute on Beam.

Pay for AI and compute work privately. Verifiable delivery, escrowed payment, on chain dispute resolution. Amounts and parties hidden at the base layer.

[Website](https://honeytones.github.io/idios-site/) · [AI and compute use cases](https://honeytones.github.io/idios-site/private-ai-escrow.html) · [Latest Release](https://github.com/honeytones/idios/releases/latest) · [Live Explorer](https://explorer.0xmx.net/?network=mainnet&type=contract&id=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f)

"Pay privately. Verify on chain. Dispute when needed."

Demo

An AI agent takes a job, privately subcontracts two parts to other agents, reviews and pays each, then settles with the client, all on Beam mainnet with amounts and parties hidden at the base layer the whole way.

Why

Public payment rails leak. Every contract, every payment, every counterparty becomes part of a permanent searchable record. For AI inference, model training, scientific compute, work that involves proprietary inputs, private data, or competitive operations, that visibility is a dealbreaker.

Idios solves the payment and settlement privacy problem. Payment is locked in private escrow on Beam. The worker locks collateral. Settlement happens on chain with amounts and parties hidden. Beam's MimbleWimble protocol hides amounts and identities at the base layer. Idios is what you get when you build escrow on that foundation.

ERC-8183 standardises the same starting primitive on Ethereum, a Job with escrowed payment for AI agent work. Idios is a separate and more complete protocol on Beam, not a port of it. It adds worker collateral and working dispute resolution, neither of which ERC-8183 has today, and it settles privately with amounts and parties hidden. Idios uses its own roles: Requester, Worker, and Arbitrator.

How it works

Two settlement modes, picked per contract at creation time.

Hash verified Settlement (Mode A)

For deterministic work where the correct output is a specific hash known in advance.

1. Requester locks payment, declares the expected result hash.
2. Worker locks collateral.
3. Worker delivers work and submits the result hash on chain.
4. If hashes match, the contract atomically releases payment plus collateral to the worker. Done.

No arbitrator involvement. Settlement is mechanical once hashes match.

Reviewed Settlement (Mode B)

For non deterministic or open ended work where the requester needs to review the output.

1. Requester locks payment, sets a review window and dispute fee.
2. Worker locks collateral.
3. Worker delivers work (uploaded out of band or via IPFS, hash recorded on chain).
4. Requester reviews the work and either:

• Approves, allowing the worker to claim payment + collateral.
• Disputes, locking the dispute fee and pushing the case to arbitration.
• Does nothing until the review window expires, after which the worker can claim payment + collateral via timeout.

1. If disputed, the M of N arbitrator registry resolves to either party by voting. The winner claims payment + collateral. The dispute fee pays the consensus voting arbitrators, never the winner.

Funds always flow to the right party. Arbitrators decide who wins a dispute and earn the dispute fee for the work of judging it, but never touch the payment or collateral.

Two phase claim

Idios uses a two phase claim pattern. Authorisation steps (approve, claim_after_timeout, and dispute resolution by M of N voting) set the contract status but never move funds. The beneficiary then calls claim to actually receive the payout, signed by their own key. This works around a Beam BVM constraint where a single kernel cannot cleanly sign for one party while routing funds to another.

Status

Live on Beam mainnet ✅

• v2 contract (Upgradable3, in place upgrades) on cid 41ef8be5. Originally deployed as v6 at block 3905992 (15 June 2026), upgraded in place to M of N v1 at block 3914637 (21 June 2026), upgraded in place again to v2 at block 3938963 (8 July 2026)
• M of N arbitration live: global arbitrator registry, voting based dispute resolution (N is 1 today). Registration hardened in v2: BEAM only, 10 BEAM minimum stake, admin co signed
• Worker reputation bonds live (v2): a worker can lock a standing slashable bond; losing an arbitrated dispute slashes it to the treasury
• Mode A end to end plus all four Mode B resolution paths verified end to end with real funds, and the full v2 slash lifecycle (bond, encumbrance, slash, treasury sweep) proven on mainnet before the production upgrade
• Dapp 3.3.0 published, supports both modes via UI

Verified resolution paths (real funds on mainnet during development; the job IDs below are from the v5 and v6 deployments that preceded the in place M of N upgrade):

Contract

CID: 41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f

Current version: v2 (SID a61f3a93), upgraded in place from M of N v1 on 8 July 2026 at block 3938963 Version history: v6 (deploy) -> M of N v1 (21 June 2026, block 3914637) -> v2 (8 July 2026, block 3938963); cid unchanged throughout Deployed at block: 3905992 (original v6 deploy; cid unchanged across all Upgradable3 upgrades) Constructor params: default_review_window=10080, arbitrator_timeout_blocks=20160, upgrade_delay=1440, min_approvers=1 Explorer: https://explorer.0xmx.net/?network=mainnet&type=contract&id=41ef8be50f0d727a919b5f5e64f7e66d5ec04442bb4f536f664e38b765e4921f

Roles

Actions per role

user actions

arbitrator actions (M of N, v2 hardened registry)

treasury actions

Status codes

0 = Open               (just created, awaiting worker commit)

1 = Active (worker has committed collateral) 2 = AwaitingApproval (Mode B, worker has delivered, in review window) 3 = Disputed (Mode B, requester has disputed, awaiting arbitrator) 4 = Settled (beneficiary can claim, payment + collateral) 5 = Refunded (terminal, requester reclaimed funds after expiry) 6 = ResolvedToAlice (arbitrators sided with requester, requester can claim; stays 6 after the claim, winner_paid in view_dispute records