Problem
A permissionless stablecoin has to do three things that pull against each other. It must remain non-freezable, so that no single party can revoke a user's balance. It must integrate with compliance regimes, so that responsible institutions can hold it without taking on regulatory risk. And it must remain credibly stable in a market without lender-of-last-resort backstops.
The privacy layer is the hard part. Compliance-aware privacy means proving things about a transaction (sender authorization, amount-in-range, regulatory eligibility) without revealing the underlying values. That is a zero-knowledge problem.
The forward-looking part is post-quantum security. Any privacy proof that protects user data today should still protect it in twenty years. SNARKs based on elliptic-curve assumptions do not have that property. STARKs do.
Constraints
Native STARK verification does not exist on Ethereum L1 today. There is no precompile, and verifying a STARK proof in pure Solidity is not gas-feasible at meaningful scale.
We are pre-launch, on Sepolia, pre-audit. Every architectural decision has to survive a real audit.
The protocol must be upgradeable in the sense that the verifier component can be swapped out without changing the rest of the system. We do not want the eventual STARK precompile (or the next zero-knowledge primitive after that) to require a fork of the protocol.
Architecture
Three layers stack up.
The stablecoin and collateral layer is conventional in shape. On-chain overcollateralization, yield-generating collateral strategies, mint and redeem flows. Where it differs from the prior art is that it does not include any freeze, blacklist, or pause mechanism on user balances. Compliance is enforced at the privacy layer, not by privileged calls into the token.
The privacy layer is a dual proof system, not a single one.
SNARKs handle the hot path. They are cheap to verify on chain and well-understood. We picked BLS12-381 rather than the more common BN254 curve specifically for real 128-bit security. BN254's effective security has been chipped at by improvements in the TNFS attack family over the years, which is fine for short-lived proofs but uncomfortable for a stablecoin that needs to stay credible across decades. BLS12-381 keeps the SNARK side honest at the security level the rest of the protocol assumes.
STARKs sit alongside as the vault layer. They are what you reach for when you need long-lived guarantees against an adversary that may or may not exist in twenty years. STARKs are post-quantum, do not depend on a trusted setup, and do not rely on elliptic-curve assumptions. The cost is proof size and verification complexity, which is why they live on the vault side rather than on every transaction.
Poseidon is the shared commitment primitive across both systems. On the STARK side, hashing happens in-trace rather than outside the trace, which costs more to prove but produces a tighter security argument. Sharing Poseidon across both circuits lets the two systems exchange commitments without translation overhead.
The on-chain verifiers are the interesting part. The SNARK side verifies natively on Ethereum L1 using BLS12-381 pairing operations. The STARK side does not have a native L1 path yet, so we wrap the STARK proof in SP1, a zero-knowledge virtual machine that produces a SNARK Ethereum can verify cheaply. Functionally, the chain verifies a SNARK that attests to the validity of the underlying STARK. Practically, the user gets STARK-level post-quantum guarantees today, with mainnet-feasible verification gas, and a clean upgrade path to a native STARK verifier when one becomes available.
Both verifiers sit behind upgrade interfaces. When native STARK verification eventually ships on Ethereum L1, swapping the SP1 wrapper for a direct STARK verifier is a one-component upgrade. The rest of the protocol does not move.
My role
Co-founder and CTO. Currently the sole developer on the technical side.
I own the protocol architecture across the stablecoin, collateral, and privacy layers. The dual proof-system design, the curve choice (BLS12-381 over BN254), and the decision to keep STARKs on the vault side rather than the transaction side. The ZK circuit work and the choice of Poseidon as the shared commitment primitive. The verifier abstraction and the SP1 wrapping for the STARK side. The pool and the compliance contracts. The developer documentation. End-to-end ownership of the engineering build through audit.
On the company side, I drive strategy and marketing across upd.io, permissionless-technologies.com, and the preview.upd.io showcase app that ties every component together.
The "team" right now is one person across protocol, app, docs, and go-to-market. That is a deliberate scoping decision for this stage, not a permanent state. The architecture is built so that hiring scales the company without forcing a rewrite of the protocol.
Outcome
Pre-launch, on Sepolia, pre-audit. The dual proof system runs end to end on testnet today. BLS12-381 SNARKs verify natively on Ethereum L1. Post-quantum STARK proofs verify through the SP1 wrapper, with a clean upgrade path to native STARK verification when Ethereum supports it. To the best of our research, this is among the first production-direction post-quantum STARK verification paths targeting Ethereum L1.
Tradeoffs
SP1 wrapping is not free. It adds proving cost and verification gas overhead compared to a hypothetical native STARK precompile. We accepted that overhead in exchange for being able to ship the post-quantum property today, with a known and clean upgrade path.
Running a dual proof system is more code surface and more audit work than a single-system design. We accepted that because each side answers a question the other cannot. SNARKs verify cheaply on chain at real 128-bit security. STARKs hold up against adversaries that do not exist yet. Picking just one would have left a structural gap in either today's verification cost or tomorrow's security guarantees.
Choosing BLS12-381 over BN254 for the SNARK side costs us in pairing-verification gas compared to BN254, which has a long-standing precompile and very tight gas economics. We accepted that for the security headroom. A stablecoin meant to outlive its first few hardforks should not be priced against the cheaper curve when the cheaper curve has a known security drift.
Permissionless and non-freezable is a strong design choice. It removes a specific class of failure mode, namely a regulator or operator using the freeze function in a way that contradicts the protocol's promise. It also removes a class of safety net that some institutions are used to leaning on. The compliance layer compensates by making it possible to participate without exposing ineligible actors to ineligible counterparties, but that is an ongoing dialogue with the broader stablecoin landscape.
The lesson I take from architecting this protocol is that the hard work in zero knowledge is not the prover. It is the upgrade story and the curve story. Build verifiers behind interfaces. Pick the curve that is honest about your security level, not the one with the cheaper gas. Assume your primitive will be obsolete in three years. Keep the rest of the protocol from caring.