Core Concepts
Understanding the fundamental principles behind SHADE Protocol.
Authorization-Based Finance
Traditional finance operates on ownership: you have money in your account, and you spend from that balance. SHADE flips this model entirely.
In SHADE, you never hold funds. Instead, you receive authorization — cryptographic permission to spend up to a certain amount within defined constraints. When you spend, funds are drawn from shared liquidity pools at the moment of transaction.
Comparison
Traditional
- You own 500 USDC
- Balance stored on-chain
- Transaction history visible
- Lose keys = lose funds
SHADE (v0)
- You can spend up to 500 USDC
- No balance, just permission
- Transactions still public (v0)
- Lose keys = lose permission only
Fog Pools
Fog Pools are shared liquidity reservoirs managed by a pool authority. When the authority issues an authorization, the authorized user can spend from the pool.
Trust Model (v0): Fog Pools are custodial. Depositors trust the pool authority to manage funds responsibly. There is no withdrawal mechanism in v0 — deposits are contributions to the pool, not retrievable balances.
How Fog Pools Work
LP Deposits → [Fog Pool] → Authorized Spends
↑ No attribution possible ↑
ZK Identity (v1 Planned)
Note: ZK Identity is planned for v1. It is NOT implemented in v0. All v0 transactions are public on-chain.
In v1, Zero-Knowledge proofs will allow users to prove authorization validity without revealing which specific authorization they hold. This is called authorization unlinking.
What v1 Privacy Will Hide (Opt-In)
- Spender ↔ Authorization link - Which authorization is being used
- Spending cap - The maximum amount authorized
- Amount remaining - How much is left to spend
What Will Remain Public
- Spend amounts (visible in token transfers)
- Transaction signers (unless relayer used)
- Protocol totals (fees collected, total staked)
- Fog Pool balances
v1 Privacy Goal
An observer cannot determine WHICH authorization a spend drew from. This is authorization unlinking, not full anonymity.
Programmable Constraints
Every authorization comes with constraints that define how it can be used:
| Constraint | Description | Example |
|---|---|---|
| Spending Cap | Maximum amount that can be spent | 500 USDC |
| Time Window | Duration the authorization is valid | 24 hours |
| Purpose | Category restricting spend usage | Subscriptions only |
| Revocability | Can be cancelled before expiry | Instant revoke |
Stateless Design
SHADE contracts store minimal state. User data, balances, and transaction history are not persisted on-chain. The protocol only verifies:
- Proof validity (is this authorization legitimate?)
- Pool solvency (can this spend be fulfilled?)
- Constraint satisfaction (is this spend within limits?)