blank. / product proofLive testnet receipts · 2026-05-25
Confidential payments and commerce

Amounts stay private.
Outcomes stay verifiable.

Blank is a payment application built with Fhenix CoFHE. People pay, sell, raise funds and exchange value without putting the amount in public view.

Open live product → See one real journey Inspect evidence
2test networks with live transaction evidence
3personas used for cross-user outcomes
Rabbydesktop EOA path driven through the live UI
01 / Problem and boundary

Public money reveals private business.

Wallet activity can expose an invoice amount, a contribution size, a commercial price or a settlement value. Blank hides the amount, not the existence of the transaction.

paid [ amount encrypted ] USDC to a public recipient. The transfer can be confirmed without disclosing its value.

EncryptedPayment amounts and confidential value handled by CoFHE contracts.
PublicSender, receiver, asset, transaction existence and workflow state.
Not claimedSender anonymity, receiver anonymity or mixer behavior.
02 / Product surface

One privacy model across real payment jobs.

The user chooses a normal financial action. Blank supplies encrypted amount handling and a visible outcome.

SendPrivate amount transfer and claim links.
InvoicesVendor payment and settlement state.
GiftsRecipient claim without amount exposure.
GroupsShared expenses with private balances.
StorefrontEncrypted pricing and buyer outcome.
CrowdfundPrivate contribution amounts.
ExchangeEncrypted P2P offer amount.
OfframpEncrypted USDC settlement lifecycle.
03 / Signature journey

Confidential commerce, seen by every party.

A real storefront path on the live testnet product. Dave offers an item with encrypted price handling, Bob pays, and Dave sees the purchased listing after returning to his seller view.

Seller / DaveCreates listingPrice is committed through the encrypted flow.
Buyer / BobPays for accessThe payment state changes and seller delivery instructions appear.
Seller / DaveSees purchaseReturning to the selling view reflects the sale.
Dave creates an encrypted storefront listing
Eth Dave creates the listing.
Bob completes the storefront purchase
Eth Bob completes payment.
Dave sees the sold storefront listing
Eth Dave sees the sold listing.
04 / Privacy architecture

The product path behind the receipt.

A user signs in Rabby. Blank encrypts the amount client-side for a CoFHE-aware contract call. The chain records the state transition and the application returns the resulting status.

01Rabby wallet

User approves the action from a standard EOA wallet.

02Blank UI

Amount input is prepared for encrypted contract execution.

03CoFHE contracts

Encrypted values are stored and processed on testnet.

04Visible outcome

The user sees status, receipt link and counterparty state.

Live application Network status Whitepaper Transaction index
Evidence appendix

Receipts, screenshots and cross-user outcomes.

This archive supports the product story above. It records desktop Rabby EOA flows driven on Ethereum Sepolia and Base Sepolia from the live application. Mobile transaction coverage and sponsored/passkey readiness are not claimed on this page.

Recorded desktop coverage

The visual sections focus on shareable and Wave 5 headline journeys. The matrix below states the Rabby EOA outcomes recorded during live QA on both Sepolia chains.

Outcome verifiedBase SepoliaEthereum Sepolia
Shield and encrypted sendVerifiedVerified
Payment request settlement and invoice settlementVerifiedVerified
Gift claim, claim link used-state, storefront sale, crowdfund contributionsVerifiedVerified
Stealth inbox, groups, inheritance, encrypted proofVerifiedVerified
Escrow delivery and releaseVerifiedVerified
P2P Exchange create and counterparty fillVerifiedVerified
P2P Offramp take, proof, challenge window and releaseVerifiedVerified
Cross-user refresh truth and failure handlingVerifiedVerified

1. Wallet identity

Three personas (Dave/Bob/Carol) on the same Rabby profile, switched between via the extension popup. Every flow below switches Rabby to the right persona before each step.

Dave verified on Ethereum Sepolia
Eth Sepolia Dave verified · 0x7eF9…D175

2. Claim Link · send to anyone

Dave creates a magic link, Bob opens it and claims, Carol is rejected on the spent link. Used → blocked enforcement is on-chain. Same flow proven on both chains.

Dave creates claim link
Eth Dave creates · /claim/11155111/<id>#<secret>
Dave creates claim link on Base
Base Same flow, /claim/84532/<id>#<secret>
Bob claims the link
Eth Bob claims · encrypted USDC moves to Bob
Bob claims the link on Base
Base Bob claims · same outcome

3. Storefront · encrypted sales

Dave lists, Bob buys, Carol can browse but can't see Bob's purchase. Dave revisits /app/sell after the buy and sees the listing in his "Your listings" section with up-to-date state. Same flow proven on both chains.

Storefront create
Eth Dave creates listing · encrypted price commit
Storefront create on Base
Base Same · encrypted price commit
Bob buys
Eth Bob pays · seller-handled delivery channel is shown after purchase
Bob buys on Base
Base Bob pays · same seller-handoff outcome
Dave seller revisit after buy
Eth Dave returns to /app/sell · sees sold listing
Dave seller revisit after buy on Base
Base Same revisit, same state

4. Crowdfund · encrypted contributions

Bob and Carol contribute privately to Dave's campaign. Their amounts are encrypted; only the on-chain total handle is visible. Dave revisits /app/fundraise and sees the campaign with both contributions reflected.

Crowdfund create
Eth Dave creates campaign · goal encrypted on-chain
Crowdfund create on Base
Base Same · goal encrypted on-chain
Bob contributes
Bob contributes 0.1 USDC · encrypted
Carol contributes
Carol contributes 0.1 USDC · encrypted
Dave creator revisit
Dave returns to /app/fundraise · sees the funded campaign

5. P2P Exchange · encrypted swap

Encrypted-amount swap offer on the P2PExchange contract. Dave creates, Bob fills, and both users see the filled result. Fresh full lifecycles were driven on the live deployment on both chains.

P2P offer created
Eth Dave creates · offer visible in My Open Offers
Ethereum Sepolia P2P offer filled by Bob
Eth Bob fills · filled trade visible in his wallet view
Base Sepolia P2P filled state for Dave
Base Dave sees the filled offer after Bob completes it
Base Sepolia P2P offer filled by Bob
Base Bob sees the completed fill state

Fresh create + fill proof · 2026-05-25

6. P2P Offramp · create (headline)

Wave 5 headline build. Dave creates an encrypted offramp offer: 1 USDC for $1 PhonePe UPI. The USDC amount is committed encrypted; the fiat rail + price are public so takers can find it. Offer appears in the public book.

Offramp create after
Base Sepolia Offer #0 in the public book · PhonePe UPI · $1.00 @ $1.0000/USDC

7. P2P Offramp · full lifecycle

Bob takes Dave's offer, follows the off-chain payment step, submits testnet settlement evidence, waits the 300-second challenge window, then releases the encrypted USDC to himself. The testnet build uses an operator-signed mock Reclaim verifier; production settlement requires an approved live proof provider and independent security review.

Bob takeOffer
Step 1 · Bob takes the offer · fill state 0 (Locked)
Bob submitProof
Step 2 · Bob submits Reclaim proof · fill state 1 (ProofSubmitted)
Bob release
Step 3 · 300 s challenge window elapses · Bob releases · fill state 2 (Released)

On-chain proof · both chains

8. Highlighted on-chain transaction index

The linked headline-flow transactions below have successful receipts on the labeled chain. Click through to Etherscan or Basescan to verify independently.

Eth Sepolia P2P Exchange lifecycle

Base Sepolia P2P Exchange lifecycle

Eth Sepolia Offramp lifecycle

Base Sepolia Offramp lifecycle

FHE invariant (mock-Reclaim signer = on-chain operator on both chains)

  • Server signer: 0xb860513A3C5348C46cF52a573Fd743bA03c2c53F (source: /api/relay kind=mock-reclaim-sign)
  • Eth on-chain: MockReclaimVerifier(0xdfc2606B…).operator() = same address
  • Base on-chain: MockReclaimVerifier(0xB36441E8…).operator() = same address
  • Verify: verifyAndConsume(sig, …) returns (true, 0x301f8c…) on both