Security and privacy
Wallet ownership, permission to operate a wallet, and access to invoice data are separate controls in Cleared. Understanding each one helps you choose what to authorize and what to share.
Safe ownership and delegated signing#
Your merchant funds are held in a Safe smart account. The embedded wallet associated with your login is its owner signer. Protect access to that login and review wallet prompts before approving them.
Cleared also supports delegated session permissions. When you enable API invoice writes, a server-held signing key can act within the session authorized on your Safe. The invoice-writing session is limited to issuing and canceling invoices through the registry, with issuance tied to your Safe as merchant. It is not a general withdrawal permission.
This means “self-custody” does not mean Cleared holds no signing keys or that every operation needs a fresh owner signature. The scope of an installed session matters. The dashboard withdrawal flow requires an explicit owner signature. See API keys, agents, and withdrawals.
Revocation has different meanings#
| Control | What it stops | What it does not do |
|---|---|---|
| Revoke an API key | Future API access using that credential. | Remove a shared signer's permission from the Safe. |
| Revoke the on-chain signer session | Use of that session after the revocation transaction confirms. | Undo transactions already executed. |
| Revoke an invoice access token | Future authorized retrieval using that token. | Erase public chain data or copies already downloaded. |
If you need to remove delegated signing authority, complete the on-chain revocation flow as well as revoking exposed API credentials. A pending revocation is not a confirmed revocation.
Encrypted invoice metadata#
Invoice metadata includes seller and customer names, contact and billing details, and the description of the charge. Cleared encrypts it with AES-256-GCM before storing it on IPFS. The server retains encrypted key material and decrypts metadata after validating access. Authorized merchant access is also available through the authenticated app.
The share link contains a bearer token: anyone who has a valid link can view its invoice details. It is not restricted to the email recipient or the wallet that eventually pays. The token is an access credential, not a decryption key delivered to the browser.
This is server-side encryption and access control, not end-to-end encryption that excludes Cleared. Access depends on Cleared's API, key storage, and metadata storage being available. See Share invoices for expiration, revocation, and link regeneration.
What remains public#
The ordinary payment flow exposes on-chain information, including invoice amounts, merchant and payer addresses, invoice status, timestamps, NFT ownership, and USDC transfers. Observers may link transactions or infer relationships from that data even when names and descriptions are encrypted.
Private payments are a separate, conditionally approved design with verification and rollout gates. They are not a privacy guarantee for today's standard invoices. See known limitations.
Verification and operational limits#
The pay page compares the decrypted metadata with its on-chain hash and blocks payment when verification fails. This checks integrity against the recorded invoice; it does not prove that the seller is trustworthy or that a charge is correct.
Paid and canceled invoices are terminal under the current contract lifecycle. Cleared does not provide a payment reversal button. Protocol contracts have administrative controls, including upgrade and fee controls, and USDC has its own issuer controls. Self-custody is not a promise that every service or token transfer will always be available.
Practical precautions#
- Protect your email account and use its multi-factor authentication options.
- Keep API keys and full invoice links out of public repositories, screenshots, and logs.
- Review the amount, network, recipient, and permissions before signing.
- Save the invoices, receipts, and accounting exports you need. Revoking a link cannot retract those files from someone who already received them.
For payment or access problems, see troubleshooting. For deployed protocol references, see contract addresses.