OpenBell

AI-RWA receivables for small suppliers, with bounded invoice funding on X Layer.

OpenBell helps small suppliers turn payer-signed invoices into bounded working capital before buyers pay. A genuine AI underwriter may approve less or refuse, but it never holds funds. OpenBell binds the resulting decision to the invoice and funder; X Layer rejects any underwriter-signed advance above the immutable contract limit and preserves the funding and settlement trail.

Live app · Try OpenBell · Live desk · Proof room · Machine-readable project evidence

Mainnet result

One complete canonical-USDG lifecycle reached SETTLED on X Layer mainnet:

Stage	Result
Supplier request	0.05 USDG
Genuine model decision	REJECT · first response · no retry
Disclosed human exception	Maximum 0.025 USDG
Contract execution	Exactly 0.025 USDG funded
Final settlement	Exactly 0.02525 USDG repaid

The settled invoice produced a 0.00025 USDG gross premium for the funder: 1% of the 0.025 USDG advance. That is the realized return for this single invoice, not an annualized rate. The deployed contract sent the complete repayment directly to the funder and charged no OpenBell protocol fee.

The human exception did not replace or relabel the model refusal. Its underwriter-signed approval carried the rejected artifact's hash as modelHash, and the published lifecycle verifier recomputes the exact decision digest recorded in the onchain invoice state. The exception could authorize only the stricter of 25% of face value or 50% of the original request.

Inspect the settled-pilot rejection preimage · Verify the settled lifecycle

Five X Layer receipts

#	Action	Mainnet transaction
1	Register dual-signed invoice	0x4d3363…67948
2	Authorize exactly 0.025 USDG	0x822b0f…4412f
3	Fund exactly 0.025 USDG	0xf17ef4…ab35a
4	Authorize exactly 0.02525 USDG	0x8fda8d…de6fb
5	Settle exactly 0.02525 USDG	0xdd8e68…658e5

Product loop

signed invoice
    -> receipt-bound AI assessment
    -> smallest authorized USDG advance
    -> direct payer settlement

1. Sign the receivable. Supplier and payer sign identical invoice terms and a local document hash through EIP-712.
2. Assess confirmed history. OpenBell derives payer history from confirmed X Layer contract events across both official RPCs. Supplier-declared performance is not accepted.
3. Fund exact terms. A funder advances only the smallest amount allowed by the request, model, and immutable contract ceiling.
4. Settle directly. The payer repays the fixed amount to the recorded funder and the invoice reaches terminal state SETTLED.

The receipt-bound pilot demonstrates how a completed invoice can supply confirmed payer history for a later assessment. Production currently uses one pinned public checkpoint; incorporating new receipts requires regenerating, verifying, and publishing that baseline. The same contract can support repeated receivables and future funders without requiring a pooled-liquidity contract.

Why the AI is load-bearing

The model produces one structured, invoice-bound decision. It may:

• lower the permitted advance;
• increase the required fee within the contract ceiling; or
• refuse and emit no executable terms.

The first valid response is authoritative and is not retried or substituted. The model cannot change the signed invoice, custody funds, bypass party signatures, exceed contract ceilings, or execute a transaction.

The trust boundary is explicit. The connected application obtains and seals one Bankr-mediated GPT-5.6 Terra response. A configured underwriter signature creates execution authority. The contract verifies that signer, the invoice-bound decision and evidence hashes, economic terms, freshness, expiry, and immutable ceilings; it does not independently attest that a remote model executed.

The mainnet assessment used a receipt-derived checkpoint through X Layer block 68,230,450:

• 1 completed settlement, on time;
• 0 open funded invoices;
• 71.42% counterparty concentration; and
• byte-identical observations from both official X Layer RPCs.

That limited, concentrated history produced the genuine result:

REJECT · LIMITED HISTORY · HIGH CONCENTRATION · NO RETRY

Inspect the separate receipt-bound decision · Inspect the checkpoint

Why X Layer is load-bearing

X Layer is not only the deployment destination. The chain provides the facts the model evaluates and enforces the economic boundary afterward:

• confirmed OpenBell receipts become the underwriting history;
• chain ID 196 and the deployed EIP-712 domain bind every signature;
• canonical USDG is transferred with exact balance-delta accounting;
• invoice state prevents duplicate funding and stale execution; and
• public receipts prove the advance, repayment, and terminal state.

Remove X Layer and OpenBell loses both its receipt-derived risk history and its settlement authority.

Growth path

OpenBell starts with small suppliers that wait for buyer payment after an invoice is signed. A settled invoice can enter a later assessment only through a regenerated, verified, and published payer-history checkpoint; this is not automatic today. The same verified contract can already process successive receivables under distinct invoice IDs and direct funder-to-supplier advances. The immediate next step is repeated supplier and funder pilots, followed by validation of acquisition, legal assignment, KYC/AML, pricing, collections, and default performance.

The adjacent receivables-finance category is established: FCI reported EUR 4.039 trillion of global factoring turnover in 2025, and IFC identifies multi-trillion-dollar MSME financing gaps while using supply-chain finance to turn supplier receivables into working capital. Those sources establish the neighboring need and financing pattern—not OpenBell's addressable market, traction, or underwriting performance.

Try OpenBell

The shortest product path requires no wallet. Open the one-click trial and select Prepare the no-wallet credit memo. OpenBell runs the real browser-side preparation engine, calculates the immutable contract limit, creates the invoice ID and document commitment, and renders an inspectable unsigned package and credit memo. The sample is explicitly testnet/no-value and makes no model, signature, financing, or transaction claim.

Surface	Purpose	Wallet required
/studio/	Run the one-click sample or prepare invoice terms, hash a document locally, and export an unsigned package	No
/mainnet/	Continue the supplier, payer, underwriter, funder, or settlement workflow	Only for the relevant role
/fund/	Complete one exact invited funding action when a verified candidate is available	Funder only
/proof/	Inspect deployment, model, lifecycle, and evidence boundaries	No

The dedicated one-wallet funding route has also been completed from a separate wallet without a file or CLI. Wallet 0x2Ef353…05244 funded exactly 0.005 USDG in 0xa9068a…e030a. The wallet, transfer, and REGISTERED -> FUNDED transition are onchain-verifiable. The same two public addresses appear with supplier and funder roles reversed between this route and the settled pilot, so this proves route completion—not independent wallet ownership, target-user demand, or independent completion of the full lifecycle.

Deployment

Field	Value
Network	X Layer mainnet · chain 196
Contract	0xc4Ef249b80a6a034198C226278c51b0a903840dd
Settlement token	Canonical USDG · 0x4ae46a509F6b1D9056937BA4500cb143933D2dc8
Deployment transaction	0x328c80…af413e
Deployment block	67,764,503
Runtime hash	0x3aa05fd1a2f966e99324c8c24dc3ee67e2f4c11a4f3c8de0da25fc1f7e8a9798

The contract is non-custodial and request-funded. It has no pool, protocol token, auction, secondary market, governance system, collections engine, partial funding, or partial repayment. Only a document hash is placed onchain.

Security boundary

OpenBellReceivables.sol uses:

• EIP-712 domain separation and ERC-1271-compatible signature checks;
• exact ERC-20 balance-delta accounting;
• replay, duplicate-funding, stale-decision, and wrong-party protection;
• reentrancy protection;
• immutable advance and fee ceilings;
• rotatable underwriting authority; and
• an originations-only pause that does not block settlement of funded invoices.

OpenBell proves signed terms, bounded decisions, exact token movement, and contract state. It does not prove legal validity of an offchain invoice, guarantee repayment, establish broad market demand, or claim that every lifecycle role was independently operated.

For X Layer builders

OpenBell is MIT-licensed and publishes reusable, fail-closed patterns rather than only screenshots:

• OpenBellReceivables.sol combines EIP-712 invoice and decision binding, ERC-1271 support, replay protection, immutable ceilings, and exact USDG deltas;
• derive-mainnet-receipt-history.ts derives payer history from confirmed contract events across two official X Layer RPC providers;
• testnet-flow.mjs validates role-bound browser action packages before a wallet can submit them; and
• verify-mainnet-lifecycle.mjs independently recomputes the published lifecycle, authority digest, token movements, terminal state, and residual allowances.

The canonical project evidence manifest gives judges and other builders one machine-readable index of the live deployment, economics, AI trust boundary, reusable components, evidence URLs, and claims not proven.

Run locally

Requirements: Node.js, npm, and Foundry.

npm ci
npm run check

For the local website:

npm run web:check
npm run web:serve

Open http://127.0.0.1:4187.

Evidence

• Pre-lifecycle mainnet deployment snapshot
• Reproducible deployment verification
• Mainnet lifecycle observations
• Deterministic lifecycle verification
• Settled-pilot complete rejection preimage
• Receipt-bound history observations
• Receipt-bound genuine rejection
• Independent one-wallet funder observations
• Deterministic one-wallet funder verification

The labelled X Layer testnet fixture remains available for reproducible testing under /operate/ and in the evidence archive. It is explicitly separate from the canonical-USDG mainnet lifecycle above.