Trust

Sandbox

What the program checks before it moves money, what the protocol does not promise, and who holds which key.

Devnet pilot, unaudited, not frozen on purpose.

Nobody outside the team has audited this program. It stays upgradeable so a fix can ship during the event: freezing a Solana program cannot be undone. That also means whoever holds the upgrade authority can change the program, so that key is shown below, read from the chain with its time.

Who holds what

The payer's phone: A P-256 key created inside the iPhone's Secure Enclave, which cannot be exported. Only that phone can sign its payment notes.
The program's vault: The sandbox tokens sit in a token account owned by the program's vault account. Only the program can move them out, and only to pay a merchant's signed withdrawal from the balance its redeemed notes credited.4oXuRDG3KixQpMYFMrJH6g9yM9YViDDwanzXdtkZWneuOwned by the vault account16.25 sandbox USDCVault token account on Solana Explorer(opens in a new tab)
The settlement server: It relays notes to the program and pays the network fees. It cannot forge a payer's note: the program checks the payer's own signature on chain, so a note the payer never signed fails there. It also signs confirmations and certificates with an Ed25519 key.Phones show Paid on its signed confirmation, and merchants accept its signed certificates offline, so whoever holds the server's Ed25519 key can sign a false confirmation or certificate that phones trust. The chain still decides who actually got paid.Its published Ed25519 key:cce245d81e79e785ddb47967ddf7aeb4f4198aae9d850fc04a0489b4872b7ad4
The upgrade authority: 4RaquyuY9zseQTP5cTBoh8bmvMRvUyJzaHeMqKcbSksSOne key, held by one teammate, can upgrade the program today. A 2-of-3 multisig is planned (task 3.46), not done.Authority on Solana Explorer(opens in a new tab)

Read from Solana devnet at slot 509733809, Sat, Oct 10, 9:18:51 PM ET, 0 s before this page loaded.

What the program checks before it moves money

The payer signed this exact note. The instruction right before redeem_note must be Solana's secp256r1 signature check, over exactly the 141 note bytes, with the payer key stored in the allowance account. The program reads it only through the canonical instructions sysvar, so a forged or substituted check fails.
The note is well formed and meant for this deployment. Its prefix, the USD currency and an amount above zero are checked on chain, and so are this program id, the devnet cluster and the configured mint. A note signed for another deployment never settles here.
The accounts are the program's own. The allowance account must be the program's account for the note's allowance id, and the merchant record the one for the note's payee.
Each serial settles once. Every allowance keeps a 256-bit map of used serials. A second note on a used serial fails on chain with the error SerialUsed.
Never more than the cap. The allowance's redeemed total plus this note must stay at or under the cap that was locked in the vault when the allowance opened.
Nothing settles late. The chain clock must be at or before the note's expiry and the allowance's expiry.
Only the named merchants, if any are named. When an allowance lists merchants (earmarks), the note's payee must be one of them.
All or nothing. Only then is the merchant's balance credited and an event logged. A failed check changes nothing.

PAYMENT-V1 section 8(opens in a new tab)redeem.rs(opens in a new tab)wire.rs(opens in a new tab)

What the protocol does not promise

Double spending is bounded, not prevented. The chain refuses a reused serial, so a payer can never settle more than the cap. A merchant who accepts a note offline carries the risk that the payer spent that serial somewhere else first. An offline limit caps that risk; the merchant's phone enforces it, not the program.
The received-at time is the merchant phone's clock. The merchant signs it; nothing proves it.
Payments are not hidden. Devnet stores key hashes, amounts and times for anyone to read, and a payment shown as a QR code is plain text that anyone who sees it can read. Changing it breaks the payer's signature, which the program checks.
Warnings and repayment are not built yet. Each allowance records a bond, held in the vault, but no instruction pays it out. Warnings that spread to nearby merchants after a conflicting spend are planned, not built.
Sandbox tokens only. The vault holds devnet USDC, a test token with no value. Nothing here moves real money.

PAYMENT-V1 section 10(opens in a new tab)