Application layer

Capture Modules

Value flows from the real world into your vault.

A capture module is a pluggable program that takes some kind of activity proof — a signed receipt, a zkTLS attestation, a location ping, an ad-view signature — and mints Cred into the associated user's vault. Each module defines its own proof format, verification rules, and reward distribution. Today only Shopping is deployed; the interface is stable and the others are in design.

ProgramHiewKE…yeteXJ

GitHub

Module interface

Every capture module implements four functions.

trait CaptureModule {
  fn submit_proof(agent: Pubkey, proof: Proof) -> Result<CaptureResult>;
  fn verify_proof(proof: Proof) -> bool;
  fn calculate_reward(proof: Proof) -> u64;
  fn get_fee_distribution() -> FeeDistribution;
}

Modules authorize themselves with Cred via register_capture_module on the Cred program. Once registered, their capture_mint calls are accepted.

Shopping module (live)

Merchant receipts → rewards.

User share

80%

Goes straight into the user's vault as Cred, atomically with the merchant's receipt verification.

Treasury share

14%

Accrues to the protocol treasury for ecosystem incentives and audits.

Staker share

Flows into the veOXO fee pool, distributable to lockers.

Max reward rate

10%

Protocol-enforced ceiling on the rewards rate any merchant can set. Configurable by the merchant within 0 – 1000 bps.

Min purchase

$1.00

100 cents. Sub-dollar transactions don't qualify, to reduce noise.

Double-claim

prevented

CaptureRecord PDA keyed on transaction_id. A tx can only be captured once, ever.

Proof paths

Three ways to prove a purchase.

01Agent-submitted receipt

User's agent presents an Ed25519-signed receipt from a registered merchant. The Solana runtime's native Ed25519 precompile verifies the signature. Security invariant: the Ed25519 instruction must appear immediately before our instruction to prevent replay.

02Merchant webhook

Merchant-side server directly submits the claim using their signing key. Suits POS integrations where the merchant sees the transaction before the user does.

03Reclaim zkTLS

Zero-knowledge proof of a banking or card-statement record — no credentials shared, no API required. Lets users earn from purchases at merchants that don't have a direct Loop integration. Pending Reclaim SDK wire-up.

Future modules

Same interface, different activities.

Each of the capture types already declared in Cred is a capture module slot:

Data — license user data feeds to buyers; license fees mint Cred.
Presence — verified location check-ins create micro-captures.
Attention — opt-in ad-viewing with watermark verification.
Work — productivity signals (long-term; requires employer participation).
Content — creative-output signals from third-party platforms.

All of these plug into the same capture_mint interface on Cred. Adding a new capture type requires a governance vote to register the module.

Merchant lifecycle

Four instructions to onboard and run.

register_merchant

Admin creates the merchant account with signing key, category, and rewards rate (≤ 10%).

fund_merchant_pool

Merchant pre-funds their Cred pool. User rewards draw from this pool — if it empties, captures halt until refilled.

submit_purchase_proof / claim_with_webhook / claim_with_reclaim

Three paths for the actual capture (see Proof paths above).

withdraw_merchant_pool

Merchant authority can reclaim unused Cred from their pool.