Local Verification
Sanke Wallet verifies everything locally — no RPCs, no centralized servers, no hidden intermediaries.
Most wallets depend on centralized RPC providers to read state, simulate transactions, fetch balances, and broadcast activity. If those RPCs go down, censor traffic, log metadata, or serve incorrect state, the wallet becomes unreliable — and the user becomes exposed.
Sanke removes this dependency entirely by running verification on your device, powered by Kohaku’s light client + minimal execution stack.
Why Local Verification Matters
Centralized RPC = a single point of failure.
RPCs can:
See your IP, metadata, and transaction patterns
Censor requests
Serve manipulated responses
Log every dApp interaction you make
Break during congestion (preventing swaps, buys, mints)
Local verification ensures:
Data never leaves your device
Your wallet works even if RPCs fail
You get honest, verifiable blockchain state
No metadata leakage
Local verification is the foundation of private, reliable onchain activity.
How Sanke Verifies State Locally
Sanke uses Kohaku’s state-verification pipeline:
1. Helios Light Client in the Browser
Sanke runs a light client directly inside the extension. It verifies:
recent block headers
validator signatures
execution payload integrity
Your device confirms chain state without trusting any provider.
2. Minimal Execution Layer (Local eth_call)
Instead of asking RPCs to simulate transactions, Sanke performs:
local eth_call execution
local storage lookups
Backed by:
TEE + ORAM, with future goals of pure cryptography (PIR)
Oblivious state reads so no one knows what storage slots you're querying
This prevents RPCs from learning:
what dApp you’re interacting with
what contract method you’re calling
what storage slot you touched
3. Secure Fallback (Killswitch-Protected)
If a fallback RPC is ever needed:
You explicitly approve it
A killswitch can disable RPC completely
Sanke hijacks RPC traffic to prevent accidental leakage
ERC-7811 asset discovery happens privately
Fallback is allowed only when:
the light client is syncing
or the user opts in
The system always prioritizes privacy-preserving paths.
How Sanke Broadcasts Transactions Without RPCs
Sanke can broadcast transactions through:
p2p relaying (optional)
Kohaku’s decentralized broadcast flow
Fallback RPC if user allows (opt-in)
Broadcasting does NOT reveal:
your address
your IP
your activity graph
Even broadcasting remains privacy-preserving.
What Users Experience
Despite sophisticated cryptography under the hood, the UX remains simple:
Balances update reliably
dApps load instantly
Simulations are accurate and trustless
No “RPC overloaded” or “network error” moments
No metadata leakage during interaction
Local verification is invisible — but it changes everything.
Why This Matters for Privacy
Every wallet leak starts with metadata:
when you load a dApp
when you check balance
when you simulate swaps
when you sign
when your RPC sees your IP
Sanke prevents all of these by verifying locally.
A private wallet cannot rely on centralized RPCs. Local verification is the only path.
Where This Is Going
As Kohaku evolves, Sanke will adopt:
full private execution reads (pure cryptographic PIR)
zk-EVM client-side verification
private pre-confirmations
privacy-first account abstraction flows
Sanke becomes the first wallet designed for the next era of trustless, private Ethereum.
Last updated