Documentation

Payment workflow

Record a client invoice and the contractor work approved for that project. When a payment arrives, match it to the invoice before generating an allocation.

The planner considers cash received, accepted work, payment terms and spending limits. Review the proposed recipients and amounts before approving a batch.

When another client payment arrives, generate a new plan. Earlier contractor payments are deducted from the amount still owed.

Balances and limits

Each project has a separate accounted balance in ProjectVault. An allocation cannot use funds assigned to another project.

The available amount is the lower of cash above the reserve and the remaining daily limit. A per-payment limit also applies. Partial payments are proposed only when the contractor’s agreed terms permit them.

The reserve limits delegated spending. The owner retains withdrawal authority, including the ability to withdraw below the reserve.

Owner approval

Deterministic validation checks eligibility, amounts, agreed terms, references and current state. The public demo uses the baseline planner. Optional model proposals must pass the same validation; invalid responses fall back to the baseline.

Live execution requires the owner’s signature for the exact batch. It binds recipients, amounts, project version, chain, vault and expiry. The operator cannot use that signature to authorize a different batch.

A pending or uncertain settlement blocks further allocations for that project until its outcome is reconciled. Reusing an execution identifier is rejected.

Using the demo

The public demo needs no wallet and does not move funds.

1. The 1,200 USDC receipt already has a draft ready for review.
2. Review 700 for Amara and 200 for Tobi, leaving the 300 reserve.
3. Run the approved batch in the demo.
4. Add the 800 USDC still owed by the client. A new draft appears automatically.
5. Review Tobi’s remaining 300 and run the final demo batch.

The project ends with 800 USDC. Fieldwork’s separate 1,000 balance is unchanged. Reset demo restores the starting state.

Receipt automation

The testnet worker watches indexed project receipts and queues allocation drafts automatically. It reads current chain state, validates the proposal and adds an in-app review notification. The owner workspace refreshes receipt activity every ten seconds while signed in.

Durable receipt IDs and worker leases prevent duplicate work. Interrupted drafts can resume after a restart. Pending settlement blocks new plans; repeated drafting failures are escalated for review. Unattributed token transfers do not trigger an allocation.

Automation stops at the draft. It cannot sign or submit a payment. The new draft worker has automated concurrency, restart and stale-state tests; its hosted end-to-end run remains pending the API deployment.

Read a payment note

In the authenticated testnet workspace, select an indexed receipt and enter the client’s payment note. A configured model extracts the invoice reference, paid amount and any statement about a remainder. Extracted values must quote the original note and agree with the recorded invoice, payer and receipt amount. Ambiguous or conflicting matches stay for owner review.

A note cannot create a receipt, change a reserve, select a replacement wallet or attribute funds. Remainder statements are unverified client statements, not confirmed income or promised payment dates. The model receives the note and invoice references; omit personal or confidential material.

The note reader has a separate model setting and a literal evidence fallback. In ten synthetic evaluation cases, the tested model-plus-fallback path was fully correct in nine, compared with seven for the literal matcher. Four cases used model output. These results do not establish accuracy on customer data.

Run a business pilot

The project review page accepts a business’s own anonymized invoice, receipt, reserve and approved contractor obligations. It uses the deterministic planner locally. Nothing is uploaded or retained in browser storage.

Ask a consenting participant to compare the proposal with their own decision, record what they would change, then export the session and feedback. Quotes require separate permission. An export contains participant-reported facts and no payment volume; review and verify the evidence before making an adoption claim.

A useful pilot includes a second session on a real project. Keep business planning sessions, testnet token movements and real customer payments separate. No business has been verified as onboarded yet.

Cross-chain invoice funding

The owner workspace includes a Base Sepolia to Arc Testnet funding flow using Circle CCTP. An invoice intent records the payer, vault, amount and fee limit before a burn is signed. Circle’s attestation and the actual Arc mint receipt are checked before the owner attributes the net USDC to the invoice.

A direct mint does not automatically credit a project. Attribution is a separate owner transaction; the receipt worker then detects the attributed funds and prepares a draft. Existing transaction hashes can recover interrupted steps without another burn.

The route’s contracts have been checked on both testnets. A completed cross-chain transfer has not yet been proven. The public preview does not provide an anonymous payment service. Paymaster, Gateway and reserve yield are outside this release.

Verification evidence

Confirmed testnet payouts and missing-response recovery are documented in the transaction report. The automated checks cover allocation constraints, owner authorization, worker recovery and cross-chain funding verification.

The payment-note experiment uses ten synthetic examples. Model output was used in four; the combined model and fallback path corrected two cases missed by literal matching. Allocation model testing has not established a benefit over the deterministic planner.

A later Claude Haiku 5.5 regression check scored ten of ten twice after an amount-parser fix, with five accepted model responses and five safety fallbacks per run. These are the same small development cases, not a production accuracy estimate. Allocation checks remain inconsistent; the latest bounded check used the safe fallback. Structured payment reasons are checked against recorded terms as well as payment amounts and limits.

An authenticated VPS check also used Haiku to match a synthetic note to an existing testnet receipt. Balances and payout jobs stayed unchanged. This verifies hosted note analysis; public API access still awaits HTTPS.

In the owner workspace, each proposal exposes its triggering receipts, model or fallback, baseline comparison and recorded facts. A pilot intake or test wallet transfer does not establish business adoption.

The two-wallet testnet report records three confirmed payouts, automatic drafts, expired-signature recovery and private workspace isolation. These controlled tests used the deterministic fallback; they are API and chain evidence, rather than a browser recording or business pilot.

Your own vault

The self-serve workspace connects MetaMask or Rabby to Arc Testnet. Your wallet deploys and owns its vault. Create one project with up to two contractors, wait three minutes for recipient activation, then deposit test USDC. The worker drafts from the payment receipt; you review and sign before Circle executes.

The preview supports invoices up to 10 USDC and batches up to 5 USDC. Your wallet pays setup and deposit fees; sponsored payouts have wallet and service limits. The API runs on a VPS, with public HTTPS awaiting the supplied domain. Until connected, the workspace shows its availability status. The allocation demo remains available.

Each wallet has a private workspace. Builder-controlled tests and unverified public testnet activity are reported separately; neither counts as a verified business pilot.

Testnet and status

Splitt is a testnet application. ProjectVault is deployed on Arc Testnet, with independently verified source code. Circle wallet execution and PostgreSQL-backed receipt indexing are implemented separately from the public demo.

On 15 October 2026 the demo scenario ran on Arc Testnet at 1/1000 scale: owner-signed batches executed by a Circle developer-controlled wallet paid 0.7 and 0.2 USDC, recorded the 0.8 USDC remainder and paid the final 0.3 USDC. The project kept 0.8 USDC and the separate project’s balance was unchanged. A deliberately lost provider response resumed as the same job without a duplicate payment. Recipients were test wallets.

The authenticated API and worker are not publicly hosted yet. The testnet workspace shows connection status and requires the configured owner wallet when enabled. It is not a mainnet payment service.

Allocation model evaluations do not establish an improvement over the baseline. No real business pilot or customer payment volume is claimed.

Review the source repository for implementation details and evidence, and the verified contract source for the deployed vault. The contract is not independently security-audited.