Live on Arc Testnet: a lien recorded, a duplicate refused, the lien releasedRead the events →

The same invoice can't be pledged twice.

A public lien registry that only a confidential workflow can write to. Not us, not a lender, not the business asking for money.

CaplaneRegistry 0xe717…e19bCheck a lien

No account. It reads the chain from your browser.

app.caplane.xyz/claims

One receivable, three verdicts

Arc Testnet · chain 5042002
  • Invoice claim recorded

    Verified against the accounting system, screened, confirmed by the debtor, underwritten.

    Encumberedblock 61,685,965
  • This claim is already pledged

    A live lien covers it. The registry does not disclose anything further about that lien.

    Refused · 7 of 7resubmission
  • Advance repaid, lien released

    The escrow settled and the receivable is free to finance again.

    Releasedblock 61,687,960

A replay of the cycle recorded on Arc Testnet between blocks 61,685,965 and 61,687,960. No lien is active right now.

Built on the infrastructure it depends on

  • ChainlinkConfidential workflow in a TEE
  • Arc by CircleUSDC-native settlement
  • PrivyOrganization wallets and policies

Every side of the deal, one registry.

Record, refuse, fund and verify, each from its own surface.

What you can switch off, and what you cannot.

Most of this system is disposable. The indexer, the tool server, the adversarial worker and these pages hold no authority: stop all four and a lien reads exactly the same, because the public lookup reads the chain from your own browser. What is left is the part that cannot be switched off — one entry point with no owner, an enclave where the claim is decided, and a registry that accepts a write only from the network's own forwarder.

Caplane architecture: a lender seals a claim in the browser and sends it to the inbox; a confidential workflow inside a TEE opens it, reads the accounting ledger and the sanctions list, checks the registry for a collision and reports through the DON forwarder, which is the only caller the registry accepts. The indexer, MCP server, adversarial harness and web surfaces sit outside that path and carry no trust.

One piece sits between: the confirmation service resolves the debtor's address from the accounting ledger and never accepts one from the caller. The enclave cannot prove the key that signed belongs to the debtor, so the link arriving at an address only the ledger knows is the whole anchor. It is the weakest link, and it is named rather than hidden.

Built for everyone who touches a receivable.

For businesses

Get an advance without handing over your customer list.

The invoice is encrypted in your browser before it leaves. Your company gets its own account with a treasury policy; there is no wallet to install.

Submit a claim

For financiers

Know a receivable is free before you fund it.

Ask the registry directly. If another lender already holds a lien, it says so, and says nothing about who they are or what the invoice was.

Check a lien

For developers

Read any lien without trusting our servers.

The SDK queries two RPCs and refuses a contract whose workflow name is not the frozen one. It never calls a caplane.xyz host.

Install the SDK

“Nobody can alter an entry, including us.”

The registry has no owner, no pause and no upgrade path. One line proves it:

! grep -q onlyOwner contracts/src/CaplaneRegistry.sol && echo "no owner, no admin, no pause"

Declared, not buried.

Trust rests on the enclave

Confidentiality depends on hardware attestation, not on pure cryptography. We say so rather than hide it.

One receivable, pledged and re-pledged

The registry holds a single lien. It was recorded, released, and recorded again — everything shown here happened to that one claim.

Our API is disposable

If api.caplane.xyz goes dark, every lien stays readable from a block explorer.

The registry capital was missing.