A model-level comparison of SPS DAM and alternative token architectures
A token architecture with bidirectional state transitions, virtual/materialized mode control, and native privacy options - while maintaining full DEX compatibility.
Virtual ↔ Real ↔ Virtual with a privacy-mode toggle. Light Protocol also supports compress/decompress, but SPS emphasizes virtual/materialized mode transitions within the same domain model.
De-materialize to return from an active SPL account back to virtual mode. Account rent outcomes are runtime-dependent and should be modeled per flow.
Virtual = private (commitment-based). Materialized = public (DEX compatible). You control your privacy-cost tradeoff.
| Feature | SPS DAM | Light Protocol | Token-2022 |
|---|---|---|---|
Token Type SPS tokens can exist as virtual state or materialize to real SPL accounts | Virtual + Real SPL | Compressed accounts | Standard SPL |
Upfront Cost (1M users) SPS uses a single pool account; Light needs Merkle tree accounts | ~0.002 SOL | ~40 SOL (tree accounts) | ~1,150 SOL |
Per-User Rent SPS virtual balances avoid per-holder token account rent; materialize only when needed | 0 (virtual) / 0.002 (materialized) | ~0.00005 SOL | 0.00115 SOL |
DEX Compatible Materialized SPS tokens are standard SPL - works with Jupiter, Raydium, etc. | |||
Privacy Mode SPS virtual balances use commitments; Token-22 has Confidential Transfers | |||
De-Materialize Support De-materialize to return to virtual mode when active SPL accounts are no longer needed | |||
Bidirectional State Model SPS: Virtual ↔ Real ↔ Virtual state model. Light can decompress back to SPL through its compressed account flow. | |||
ZK Proofs Required SPS verifies Groth16 proofs on-chain; Light requires Groth16 with Photon; Token-22 uses range proofs | Groth16 (on-chain verifier) | Groth16 (off-chain prover) | Range proofs |
On-Chain Tree Accounts Light needs Merkle tree accounts (~0.0089 SOL each); SPS uses inscription logs | |||
Indexer Dependency SPS validates on-chain; indexer is convenience. Light needs Photon to function. | Optional | Required (Photon) | None |
Regulatory Compliance SPS has Proof of Innocence, auditor reveals, and compliance channels | |||
Runtime Framework SPS uses Pinocchio (zero-copy, zero-alloc Solana framework) with the Jiminy macro layer — no heap allocation, minimal CU overhead. Light uses Anchor which adds runtime overhead. | Pinocchio + Jiminy | Anchor | Native (Solana runtime) |
Trusted Setup SPS Schnorr/IAP path needs zero trusted setup — no ceremony, no toxic waste. Light requires a trusted setup for all ZK operations. SPS also offers an optional Groth16 path for full ZK privacy. | None (Schnorr path) | Required (Groth16) | None |
Programs Required SPS runs the entire 133-operation protocol from a single 369KB program plus a dedicated ZK verifier. Light requires separate programs for compression, merkle trees, nullifier queues, and more. | 1 program + 1 verifier | 4-5 programs | 1 program |
Protocol Fees SPS IAP/Schnorr transfers charge zero protocol fees — only Solana base tx fees. ZK transfers charge 100-400 lamports (fee tier) to the treasury. Light Protocol operations may include relayer fees. | 0 SOL (IAP) / ~100 lamports (ZK) | Variable (relayer) | 0 SOL |
Operations Available SPS covers tokens, messaging, accounts, ZK transfers, gasless relay, privacy, DeFi, NFTs, DAM, and inscription compression — from two coordinated programs. | 133 across 10 domains | ~10 | ~15 |
For 1 million token holders
* SPS DAM assumes 5% of users actively trade on DEXes (materialize). 95% stay in virtual mode.
┌─────────────────────────────────────────────────────────────────────────┐ │ SPS DAM ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ LAYER 1: TOKEN-2022 POOL (~0.002 SOL total) │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ │ │ Pool Account (Token-2022) │ │ │ │ │ │ • Immutable Owner: Pool PDA │ │ │ │ │ │ • Permanent Delegate: SPS Program │ │ │ │ │ │ • Holds: ALL pooled tokens │ │ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ LAYER 2: VIRTUAL STATE │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ ┌────────────────┐ │ │ │ │ │ User A: 1000 ░░░ │ │ User B: 500 ░░░░ │ │ User C: 250 ░░ │ │ │ │ │ │ (commitment) │ │ (commitment) │ │ (commitment) │ │ │ │ │ └──────────────────┘ └──────────────────┘ └────────────────┘ │ │ │ │ Stored in: Transaction logs (inscriptions) │ │ │ │ Privacy: Hidden in commitments (optional) │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ LAYER 3: MATERIALIZATION (On-Demand, ~0.002 SOL) │ │ │ │ │ │ │ │ User wants to swap on DEX? │ │ │ │ 1. Submit Merkle proof of virtual balance │ │ │ │ 2. Program creates real SPL account │ │ │ │ 3. Transfers from pool to user account │ │ │ │ 4. User pays ~0.002 SOL rent │ │ │ │ ✓ Now DEX compatible! │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ LAYER 4: DE-MATERIALIZATION │ │ │ │ │ │ │ │ User done trading? Return to privacy: │ │ │ │ 1. Transfer tokens back to pool │ │ │ │ 2. Close SPL account │ │ │ │ 3. Close account and return to virtual-state flow │ │ │ │ 4. Balance returns to virtual/private │ │ │ │ ✓ Materialized and virtual paths remain interoperable │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────┘
How each protocol validates transactions — and why Styx's Schnorr-based approach is fundamentally different from "ZK Compression"
Groth16 SNARK
~200,000 CU
REQUIRED - Photon reconstructs state from tree
None - data is public, just compressed
Range proofs (ElGamal)
~100,000 CU
Not needed - state in account
Partial - amount hidden, addresses public
Groth16 BN254 (ZK) or Ed25519 Schnorr (IAP)
~5K CU (Schnorr) / ~200K CU (ZK)
OPTIONAL - convenience layer only
Tiered: Direct delivery (Send) → Sender-hidden (IAP/Schnorr) → Full anonymity (ZK/Groth16)
User signs transfer with Schnorr signature (Ed25519). Includes commitment and nullifier.
On-chain program verifies: signature valid, nullifier not spent, commitment well-formed.
Nullifier stored in PDA (0.00089 SOL) — prevents double-spend forever. No tree needed!
New commitment inscribed in transaction logs. Indexers (optionally) watch for updates.
Unlike Light Protocol where you must query Photon (Helius) to know your balance, Styx uses a fundamentally different model:
💡 Indexer outages have different impact by architecture. SPS validation remains on-chain; balance discovery may require direct RPC/log queries when indexers are unavailable.
| Aspect | Light Protocol | Token-2022 CT | Styx SPS |
|---|---|---|---|
| Cryptographic Primitive | Groth16 SNARK | Bulletproofs + ElGamal | Schnorr (Ed25519) + Optional Groth16 |
| Compute Units | ~200K CU | ~100K CU | ~5K CU (Schnorr) |
| State Location | Merkle tree accounts | Token accounts | Transaction logs + PDAs |
| Indexer Dependency | Required (Photon) | None | Optional (any Geyser) |
| If Indexer Dies | ❌ Protocol unusable | ✅ No impact | ✅ Query logs directly |
| Double-Spend Prevention | Nullifier queue | Account balance | Nullifier PDAs (on-chain) |
| Privacy Model | ❌ None (just compressed) | ⚠️ Amount only | ✅ Tiered: Direct → IAP → Full ZK |
| Trusted Setup | Required (ceremony) | None | ✅ None (Schnorr path) |
| Programs Required | 4-5 programs | 1 program | ✅ 1 + 1 verifier |
| Protocol Fees | Relayer variable | 0 SOL | ✅ 0 SOL (IAP) / ~100 lamports (ZK) |
SPS offers three privacy methods. Choose based on your threat model — from simple link privacy to full zero-knowledge anonymity.
Tokens are delivered directly to the recipient in a single atomic transaction — no claim codes, no recipient action needed. Routes through the SPS pool for protocol standardization. Privacy is minimal; use IAP or ZK for anonymity.
Can recipient see sender? Yes — sender signs the transaction.
The sender's pubkey is visible as the tx signer, but the recipient is hidden behind a commitment hash. The output commitment is keccak256("STS_NOTE_V1" || owner_secret || amount || nonce) — the recipient's identity is inside the hash, invisible on-chain.
Can recipient see sender? No — they receive an encrypted note. The sender's pubkey is in the tx, but the recipient doesn't know which tx is theirs.
The Groth16 proof proves validity without revealing any inputs. The payer's pubkey is visible as the SOL fee payer, but reveals nothing about the logical sender — the payer could be a relay. Sender, recipient, and amount are all processed inside the ZK circuit.
Can recipient see sender? No — even the fee payer could be a different party. The proof reveals nothing.
Airdrop/mint creates virtual balance. Zero cost, full privacy.
Send to other SPS users. Still virtual, still free.
Need to swap? Create real account (~0.002 SOL).
Done trading? Return to pool and continue in virtual mode.