Tokened Architecture
Tokened Architecture
Why SnarkSide Requires a Native Token
SnarkSide operates not merely as a DEX, but as a distributed zero-knowledge computation protocol—with encrypted intents, shielded margin, and zk-verifiable liquidation logic. These operations introduce unique cost, coordination, and incentive structures that cannot be sustained or balanced by ETH or SOL alone. This section details why SnarkSide is inherently token-native, not just for governance, but as a foundational layer for proving, relaying, liquidity provisioning, and anonymous liquidation services.
1. Economic Coordination in a Private System
In transparent systems, activity can be tracked and attributed. But SnarkSide is deliberately anonymous—vaults are shielded, orders are intent-based, and actors cannot be trivially audited or reputation-scored.
As a result:
Work (relaying, proving, liquidating) must be paid without identity tracking.
Costs (proof generation, batch posting, oracle fees) must be settled off-chain or through a gasless trust-minimized model.
Participation must be permissionless, yet Sybil-resistant and rational.
This requires a cryptoeconomic primitive that acts as:
A unit of account for proving and matching work
A bonding mechanism for ensuring relayer honesty
A fee medium for system interactions
→ The SnarkSide token ($SNSD) is that primitive.
2. Native Incentive Design
SnarkSide aligns three classes of actors:
Relayers
Aggregate intents, match trades
Paid in $SNSD per verified batch
Provers
Generate zkProofs
Paid per valid SNARK
Liquidators
Submit valid ZK liquidation
Claim bounty via shielded TX
Without a native token:
There is no programmable reward structure for off-chain work
Gasless intents (signed messages) cannot be monetized
Anonymity becomes incompatible with rational work
$SNSD allows programmatic fee routing and incentive allocation while preserving user privacy.
3. Proof-of-Execution Security
In SnarkSide, value is not created through staking or governance—it’s created through ZK computation and MEV-resilient execution. $SNARK enables:
Fee markets for proving capacity: Users submit intents with attached fees; relayers and provers compete to include them.
Matching priority markets: Users can signal urgency or price sensitivity with optional $SNARK tips.
ZK auction mechanisms: Used in recursive proof aggregation and liquidity matching optimization.
This creates a computational economy, where resources are priced cryptographically, not socially.
4. Privacy-Preserving Payment
SnarkSide supports:
Shielded payment flows using ZK-enabled payment circuits
One-time fee commitments embedded in trade intents
Merkle-based LP earnings claims (private staking)
All of these require a token that can:
Exist off-chain (pre-intent match)
Be blinded (in payment)
Be redeemable privately (without leaking recipient address)
This is incompatible with ETH, which lacks shielded transfer capabilities and privacy-focused accounting.
5. Governance for Cryptographic State Transitions
The protocol includes upgradeable elements:
New circuits (e.g. Halo2, zkVMs)
New proof systems
New oracle integrations
L2 migration
Funding rate formula changes
$SNSD holders govern these via hash-locked governance commits, not via transparent vote tokens. This allows:
ZK-protected signaling
On-chain proposal verification
Private quorum evaluation
6. Token as Collateral (Optional)
Future versions of SnarkSide may allow:
$SNSD-margined positions
LP vaults denominated in $SNARK
Recursive trade networks collateralized by native token locks
This closes the loop, making $SNSD not just functional—but integral to every pathway in the system.
Summary
SnarkSide is not just a private DEX—it’s a cryptographic execution layer that must coordinate anonymous actors performing off-chain ZK computation.
The native token ($SNSD) is required for:
Incentivizing relayers, provers, liquidators
Facilitating shielded, anonymous payments
Running fee markets without identity
Governing zk circuit transitions
Powering recursive proof networks
Without $SNSD, SnarkSide would be technically viable but economically inert—unable to sustain the encrypted, modular, and permissionless infrastructure it was built to be.
Last updated