Technical specification & protocol vision
Zero-Knowledge Privacy Rails on Solana.
In simple terms: $NORTH lets you send and receive value on Solana without anyone seeing the amounts.
Vision & Mission — The Grey Space
“The world is noisy. We have built the silence. The network validates — only the sender and receiver know the cargo.”
In 2026, every transaction on Solana is a public data point. Payrolls, treasury movements, corporate strategies, personal transfers — all exposed, all traceable, all exploitable. Solana won the speed war, but absolute transparency has become a strategic liability.
$NORTH Protocol operates in what we call the Grey Space — the necessary middle ground between total transparency and total anonymity. We are not building a tool for hiding. We are building infrastructure for institutional-grade privacy that coexists with regulatory compliance.
The Grey Space is where the real world operates. Banks don't broadcast wire transfers. Hospitals don't publish patient payments. Yet today, any entity operating on Solana exposes every financial interaction to competitors, adversaries, and front-running bots. $NORTH closes this gap.
Every on-chain transaction reveals amounts, participants, and timing. MEV bots extract value from public mempools. Pattern analysis destroys financial privacy.
Encrypted deposits, confidential transfers, and ZK-proven withdrawals. The network validates integrity without knowing the content. Privacy with provable compliance.
Our core thesis: Privacy is not the opposite of compliance — it is a prerequisite for it. Institutions cannot adopt blockchain at scale without the ability to protect sensitive financial data while still satisfying auditors and regulators.
Technical Architecture — The Sentinel Protocol
Sentinel is the core Solana program deployed on devnet at address C2WJzwp5XysqRm5PQuM6ZTAeYxxhRyUWf3UJnZjVqMV5. It contains 16 on-chain instructions, 7 account types, and 19 custom error codes. Built with Anchor framework 0.31.1.
The architecture consists of three interlocking layers:
Silent Rails
Initialize · Pause · Unpause · Seal · Deactivate
5 CORE instructions. Compliance layer. Each Rail is a PDA owned by an authority holding $NORTH. Rails can be paused, sealed with an immutable audit hash, or deactivated with a reason code.
ZK Handshakes & Vaults
Create Handshake · Revoke Handshake · Initialize ZK Vault · Prepare Receive SOL · Verify State
4 CORE instructions. Handshakes establish a ZK link (commitment + nullifier). ElGamal-encrypted vaults with per-asset VaultAssetState.
Confidential Transfers
Deposit · Deposit Token · Withdraw · Withdraw Token · Transfer · Transfer Token · Get Balance
7 ZK instructions. SOL and SPL tokens deposited, transferred confidentially, withdrawn with ZK proofs. Nonce uniqueness controls.
◆ $NORTH token gate: Rail initialization requires the authority to hold $NORTH tokens.
| Instruction | Layer | Type | Description |
|---|---|---|---|
| initialize_rail | Rails | CORE | Create a new privacy rail (requires $NORTH) |
| pause_rail | Rails | CORE | Pause all operations on a rail |
| unpause_rail | Rails | CORE | Resume operations |
| seal_rail | Rails | CORE | Immutable audit seal (32-byte hash) |
| deactivate_rail | Rails | CORE | Permanent shutdown with reason code |
| create_handshake | ZK Layer | CORE | Establish ZK link (commitment + nullifier) |
| revoke_handshake | ZK Layer | CORE | Revoke an active handshake |
| initialize_zk_vault | ZK Layer | CORE | Create ElGamal encrypted vault |
| prepare_receive_sol | ZK Layer | CORE | Prepare vault to receive confidential transfers |
| deposit | Transfers | ZK | Deposit SOL into vault pool |
| deposit_token | Transfers | ZK | Deposit SPL token into vault |
| withdraw | Transfers | ZK | Withdraw SOL with ZK proof |
| withdraw_token | Transfers | ZK | Withdraw SPL token with proof |
| confidential_transfer | Transfers | ZK | Private SOL transfer between vaults |
| confidential_transfer_token | Transfers | ZK | Private SPL transfer between vaults |
| get_balance | Transfers | ZK | Query encrypted vault balance |
Total: 16 instructions — 9 CORE for infrastructure and compliance, 7 ZK for privacy-preserving value transfers.
Transaction Flow & Privacy Model
A complete privacy cycle in Sentinel follows five sequential phases. Each phase is a real Solana transaction, verifiable on-chain.
Init Rail + $NORTH gate
Handshake (commit + nullifier)
ZK Vault (ElGamal keypair)
Deposit (SOL or SPL)
Transfer (vault → vault)
Each phase = 1 Solana transaction · verifiable on Solscan devnet.
Privacy model: The current implementation uses encrypted amount fields (64-byte ElGamal ciphertexts) and 128-byte proof slots. The on-chain program validates proof length and structural integrity. Phase 03 of the roadmap will integrate Groth16 circuits for full zero-knowledge proof verification.
Nullifier model: Each handshake consumes a unique nullifier. The NullifierRegistry marks it as spent. Attempting to reuse a nullifier triggers NullifierAlreadyUsed — the same double-spend prevention model proven by Zcash and Tornado Cash.
$NORTH Tokenomics — The Key to Silence
$NORTH is not a utility afterthought — it is the access key to the entire privacy infrastructure. The Sentinel program enforces on-chain that only wallets holding $NORTH tokens can initialize privacy rails. No tokens, no authority.
Total supply
Transaction tax
Liquidity locked
Token structure
- Total supply: 100,000,000 $NORTH. Mint authority: REVOKED. Metadata: FROZEN. Contract: IMMUTABLE.
- Deflationary model: 2% tax (1% treasury, 1% operations). Progressive burn: 25% at $100k MC, 50% at $1M MC. 100% of protocol service fees for buyback and burn.
- Allocation: 15% architect allocation vested 6–18 months. 80% liquidity locked 2 years. No pre-sale, no VC allocation.
Hold $NORTH → unlocks Rail Authority → initialize_rail → enables full protocol (Vaults, Handshakes, Deposits, Transfers, Compliance). Protocol fees → Buyback → Burn → increased scarcity.
Yield & Adaptive Strategy
Sentinel introduces adaptive yield on vault assets: deposited SOL and SPL tokens can be allocated to yield strategies while remaining fully encrypted and compliance-ready. A single volatility threshold determines strategy selection — below the threshold, capital is allocated to lending (e.g. Kamino, Marginfi); above it, the protocol switches to delta-neutral strategies (e.g. Drift) to preserve principal and reduce exposure.
Max drawdown and circuit-breaker guards are enforced before any allocation. Yield accrues inside the same ZK vault model: balances stay encrypted, and only the vault owner can prove and withdraw. Protocol service fees from yield are used for $NORTH buyback and burn, reinforcing the deflationary loop. This makes Sentinel the first privacy rail where silence and yield coexist without leaking amounts or breaking compliance.
- · Volatility oracle → strategy switch (lending vs delta-neutral)
- · Max drawdown & circuit breaker → no allocation until safe
- · Yield accrual inside encrypted vault state
- · Protocol fees from yield → buyback & burn $NORTH
Security, Compliance & ZK Cryptography
Sentinel is designed from the ground up with security and compliance as first-class concerns — not afterthoughts bolted on after deployment.
Authority verification (has_one = authority), token gating for rails, 19 custom error codes, PDA determinism. No silent failures.
Rails can be paused, sealed with audit hash, or deactivated with reason code. First privacy protocol designed for institutional adoption.
Zero-Knowledge Proof Pipeline (Phase 03)
Client side
1. Secret + Amount → 2. Generate ZK Proof → 3. ElGamal Encrypt → proof + ciphertext
Solana on-chain
4. Verify Groth16 Proof → 5. Check Nullifier → 6. Update Vault State
Result
Amount: HIDDEN · Sender: VERIFIED · Proof: VALID ✓
The network validates integrity without knowing the content.
- Groth16 ZK-SNARKs: Phase 03 integrates Groth16 via Solana alt_bn128 precompiles. Proofs verify commitment and amount without revealing either.
- ElGamal encryption: Vault balances encrypted with ElGamal public keys. Homomorphic properties allow balance updates without decryption.
- Audit seals: seal_rail writes a 32-byte audit hash to the rail — immutable compliance trail.
- 19 error codes: RailInactive, NullifierAlreadyUsed, AlreadyWithdrawn, InsufficientVaultBalance, InvalidProofLength, and 14 more.
Disclaimer
This litepaper reflects the current deployed architecture and its security direction. Groth16 expansion remains an active roadmap track; deployed controls already enforce deterministic authority, replay resistance, and auditable operational safeguards. $NORTH tokens are not securities and carry no guarantee of value. Always do your own research.