Payments & fees

Deposit a fixed-denomination note

1. Create and encrypt a note locally, then discover a verified vault with deposit capacity.
2. Prepare the public deposit plan and complete required token registrations or NEAR storage-credit top-ups.
3. Approve principal plus the 0.15% deposit fee. Account for NEAR storage and gas separately.
4. Wait for finalized deposit Active state. A submitted wallet transaction does not establish acceptance.

Create a note in your browser

Page-hide and persisted browser-cache return lock the active note and invalidate unfinished work before restoring a private view. Reopen the encrypted backup to continue. This does not guarantee physical memory erasure.

1. Import an independently approved testnet FT policy on Private notes. Create and confirm a passphrase, then generate a note locally. No wallet or API is needed for generation.
2. Download the encrypted note and reopen that file with its passphrase to verify the full policy and commitment. Keep the file and passphrase separately; locking or leaving requires the backup to reopen it.
3. Enter the matching Settlement API and your receipt root, or generate a fresh random reference for a deposit without evidence. Optionally choose a vault; the default scan verifies up to 20 registry records.
4. Prepare and inspect the public deposit plan. Download it and import it in Settlements with the same policy, then approve each registration, storage and payment call. A plan does not reserve capacity or confirm payment.
5. Keep the encrypted note for withdrawal proving in Local proofs or the CLI. Browser note backups work directly with shared-spend-args or group-spend-args; private notes and passwords never reach the API.

Generate and verify a local proof

An unsafe development setup remains visibly labeled. File integrity does not qualify the setup ceremony, current liquidity, recipient readiness or final payment. The proof file contains public recipient, vault, reference and nullifier-hash data; keep the encrypted note separately.

Locking, page-hide and persisted cache return cancel pending workers and clear the open note. Cancellation alone keeps the note open for an explicit retry. Physical memory erasure cannot be guaranteed. Connected note-to-invoice proving is available in checkout; physical mobile-device qualification remains separate work.

1. Open Local proofs and import the note’s independently trusted testnet FT policy. Reopen its encrypted backup locally; the passphrase and secrets never reach the API.
2. Select the release’s proving manifest, circuit WASM, proving key and verification-key JSON. Enter the artifact manifest SHA-256 from an independent trusted source. Each file hash and the raw policy verifier binding must match before proving.
3. Select a verified payout vault in the original group and load its finalized public snapshot, or import the public snapshot JSON. The worker rebuilds the complete ordered tree and checks its root locally.
4. Set the exact recipient and disclosure root. For invoices, copy the signed recipient and selected unit reference exactly. Generate the proof locally, or cancel to terminate the worker and discard unfinished results.
5. Download the verified proof file or public withdrawal plan. Verify an existing proof file to check its canonical payload checksum and Groth16 proof again. Import the public plan in Settlements for wallet review and final reconciliation.

Pay a recipient

For invoices, choose a unit in checkout, open your saved original-group encrypted note and generate its proof locally. The signed recipient and unit reference are derived automatically. Select an eligible original-group vault. Standalone Local proofs and settlement CLI remain alternatives.

The note provides the principal. The fee payer separately covers the withdrawal protocol fee and applicable NEAR costs. The recipient receives the full fixed-denomination principal.

0.15% added on each side

Fees are calculated per note at 15 basis points, rounded down in atomic units. NEAR gas, token registration, storage credit, and first-use bonds are separate. Review the actual preflight quote.

Keep NEAR costs separate

For a native 1 NEAR note, the current 0.02 NEAR storage charge gives a 1.0215 NEAR deposit attachment. Withdrawal attaches 0.0215 NEAR separately while the recipient receives 1 NEAR. Network gas is additional.

FT groups keep token principal/fees separate from NEAR storage and gas. A token symbol is not a trust anchor: use the independently pinned token account and reviewed metadata.

For FT actions, applicable storage is 0.02 NEAR; first-use sender credit adds a 0.005 NEAR ledger bond per target contract. Token registration, account activation, gas and the FT transfer’s one-yocto attachment remain separate. Retrying an existing payout does not charge the protocol fee again.

Confirm before treating it as paid

• Check finalized deposit Active or withdrawal Complete state with the expected bindings.
• Reconcile invoices against finalized withdrawal_succeeded records.
• Check index coverage and its checkpoint. Refreshing the index is not a latest-chain assertion.
• A redirect, wallet callback, transaction hash, or timeout is not a final payment result.

Prepare the receiving account

Use Check recipient on the invoice form before signing, or in checkout after independently importing the trusted policy and verifying its API. Prepared withdrawals also offer this check for their bound recipient. No wallet connection is needed for this read-only lookup.

Account activation, token registration and payment review are separate steps. A pre-registered token record does not activate a missing account. Activate the exact account with a compatible NEAR wallet, then refresh. The app does not estimate an account-creation amount or send a funding transfer.

For an existing, unregistered account, inspect the public storage_deposit call and exact token storage minimum read at the checked final block. The payment session presents registration separately for wallet approval; gas and protocol fees remain separate.

Ready for payment review is a snapshot of account existence and registration. It does not establish ownership, available gas, payer balance, vault liquidity or payment completion. Changing recipient, policy or API invalidates the result; failed refreshes clear previous readiness.

Attach a receipt commitment

Create and back up a private receipt in Evidence. On Private notes, import a selected disclosure with Import receipt root from disclosure JSON. The browser verifies the file locally and puts only its root in the public deposit request. It does not upload business values or opening salts.

Root import does not establish a completed payment or truthful declarations. Failed imports clear the previous root and prepared plan. Keep the full encrypted receipt so you can disclose additional fields later.

Invoice checkout requires its signed-derived per-unit withdrawal reference. An arbitrary receipt root cannot replace that reference. Generic receipt-root actions and invoice-bound withdrawals are distinct; a combined invoice/business-evidence commitment needs a separately designed format.

Choose a delivery window

Open Scheduled delivery at /relay/ after generating a public withdrawal proof. Import your independently trusted group policy, choose immediate delivery or a randomized window, and review the original recipient, principal and additive 0.15% fee. The configured sponsor pays gas, storage and this fee; principal goes directly from the vault to the recipient.

Save the recovery receipt before confirming. One execution time is persisted for each accepted request; batches contain at most eight separate transactions and never wait for more users. Timing dispersion does not create independent participants or guarantee anonymity. The hosted frontend has no bundled running relay.

1. Confirm once and track the waiting window. A visible tab refreshes status with read-only requests. Payment confirmation uses finalized contract state, not transaction acceptance.
2. Cancel only before execution starts. Expired or cancelled delivery can be explicitly rescheduled with the same request and proof; blocked preflight can be resumed within its original deadline. Cancellation does not revoke a proof already shared elsewhere.
3. After timeout or reload, import the same policy and recovery receipt, then check the original request. No automatic resend occurs. Reconcile uncertain original hashes before any explicit payout retry.

https://github.com/Company-privacy-settlement/Core/blob/main/docs/SCHEDULED_DELIVERY.md