Tags → #solana
-
Fitting F_RP in 656 bytes on Solana
Concrete F_RP instantiation on Solana. Groth16 over BN254, Poseidon Merkle, indexed nullifier tree, BN254 Pedersen, transaction in 656 of 1,232 bytes, 235K of 1.4M CU.
-
SPST: a self-paying shielded transaction model
First construction in F_RP. The SPST relation, balance conservation under DLOG, double-spend resistance under collision-resistant PRF, unlinkability under DDH, simulation-extractable non-malleability.
-
Merkle inclusion proofs over compressed account state on Solana
How a 32-byte hash and a logarithmic path replace a multi-kilobyte account. Walk the tree-height math, the Light Protocol compressed-account model, and an inclusion-proof construction you can run in Node.
-
Relayerless privacy on a Turing-complete L1: an intro to F_RP
A series-opening map of the relayerless full-privacy framework I've been writing up. Five cryptographic games, four constructions (SPST, PPST, TAB, UPEE), one main theorem — and why it matters that the target chain is Solana.
-
Stuck Sell, Post-Graduation: Fixing a Trapped-Funds Bug Without a Redeploy
A graduated launchpad token left users unable to sell. Fix shipped without redeploying the program: a frontend conversion path that withdraws SPL, compresses, then sells through the AMM.
-
Nullifiers without the witchcraft
Nullifier Generation is on the ZERA front page next to Pedersen Commitments and Zero-Knowledge Proofs. The Rust + TypeScript implementations are six lines apiece. Here is what they actually do, and why the design borrows from Zcash.
-
144 Tests and a Surfpool Devnet
How the Zera SDK got from "scaffolded" to "trustable" — a 144-test Vitest suite, a Surfpool-forked devnet running on a Latitude box, and a quickstart that actually works.
-
x402 Vector 2: partial-signing instruction injection
The x402 client builds and partially signs the entire VersionedTransaction. A facilitator that validates structure but not bytes can co-sign a tx with extra clawback / drain instructions appended after the legitimate transfer.
-
x402 Vector 1: settlement race condition
Coinbase x402's verify→settle pipeline isn't atomic. A client can submit the same PAYMENT-SIGNATURE to multiple facilitators in parallel, or race the facilitator with a direct on-chain submission. Double-spend within blockhash validity (~60s).
-
x402 Vector 3: facilitator gas drain
x402 facilitators pay all transaction fees and the spec defines no per-client rate limit. A flood of valid-looking transactions that fail at maximum compute-unit consumption is a per-request economic attack on the facilitator.