Not marketing.Engineering.

Abstract

Sanect is a Layer 1 blockchain that provides Ethereum-compatible smart-contract execution with native, opt-in transaction privacy.

It is built as a dual-stack system: an EVM execution layer atop a Cosmos SDK consensus base, connected by a precompile bridge. The shielded-transfer primitive uses a Penumbra/Zcash-Sapling-inspired UTXO note pool verified by zero-knowledge proofs (Noir, UltraHonk) over Aztec’s universal Barretenberg SRS — no per-circuit trusted setup ceremony. The network targets sub-second BFT finality with an active validator set of 50, selected by staked SNCT weight from an unlimited registration queue. Genesis supply is one billion SNCT minted at TGE, with Cosmos Hub-style 7–20% inflation as the ongoing validator security budget.

1 — Problem statement

Public blockchains expose every transaction to permanent, global surveillance. Sender addresses, receiver addresses, amounts and the complete transaction graph are permanently indexed and freely queryable. This design choice, appropriate for consensus correctness, is a categorical liability for commercial and personal use.

Existing privacy solutions introduce unacceptable compromises:

• Privacy-native chains (Zcash, Monero) require separate ecosystems — users must bridge assets, learn new tooling and accept inferior DeFi liquidity.
• Mixer protocols (Tornado Cash) are bolt-on, fragile under regulatory pressure, and leak metadata through usage patterns.
• Trusted execution environments (Oasis) require hardware trust assumptions that are opaque to end users.

Sanect’s thesis: privacy should be a first-class primitive on the same chain as public execution, with no new seed phrases, no bridge risk and no ceremony-based trusted setup. Users choose per transaction whether to transact publicly or privately — both paths use MetaMask and standard EVM tooling.

2 — Architecture

The Sanect node is a single binary integrating two execution environments: an EVM interpreter and a Cosmos SDK application chain. They connect at the message layer — EVM transactions are translated into Cosmos SDK messages before entering the consensus engine.

2.1 EVM layer

The EVM layer implements the Ethereum JSON-RPC interface (eth_*, net_*, web3_*) and executes EVM bytecode identically to Ethereum mainnet at the Paris hard-fork level. Gas metering, opcode semantics and ABI encoding are fully compatible; existing Solidity contracts deploy without modification.

2.2 Cosmos SDK base

The consensus and state layer is a standard Cosmos SDK application chain running CometBFT Byzantine fault-tolerant consensus. This provides deterministic finality within one block, IBC compatibility for cross-chain messaging, and native staking and governance modules. The unbonding period is 21 days; slashing applies to equivocation and extended downtime.

2.3 Precompile bridge

Precompiles are EVM contracts at deterministic addresses that delegate execution to native Go code, exposing Cosmos modules to Solidity and to any EVM wallet:

0x0000000000000000000000000000000000000800  // staking
0x0000000000000000000000000000000000000801  // distribution (rewards)
0x0000000000000000000000000000000000000804  // bank
0x0000000000000000000000000000000000000805  // governance
0x0000000000000000000000000000000000000806  // slashing
0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE  // WERC20 (native SNCT as ERC-20)

3 — Privacy model

The shielded pool is an EVM smart contract implementing a UTXO note scheme. Unlike account-based privacy, note-based privacy treats each transfer as a discrete note — a cryptographic tuple consumed and produced by each transaction. The chain stores only commitments (hashes) and nullifiers (spent markers), never amounts or addresses in plaintext.

3.1 Note commitment scheme

A note n is defined as n = { asset, value, owner_pk, salt }. The commitment is cm = Poseidon2(n). Commitments are inserted into an append-only depth-32 Merkle tree. To spend a note, the spender proves in zero knowledge that they know an n such that cm is in the tree and that they hold the spending key. The nullifier nf = PRF(spending_key, cm) is published to prevent double-spending.

3.2 Noir proof system

The spend circuit is written in Noir — Aztec’s language for zero-knowledge circuits — and proven with UltraHonk via the Barretenberg backend. Noir was chosen for three reasons:

• No per-circuit trusted setup. Barretenberg uses a universal structured reference string that is already public and audited, eliminating Groth16’s toxic-waste problem.
• Browser proving. Noir compiles to wasm; client-side proof generation takes roughly 2–3 seconds on a laptop — no server-side prover.
• Actively maintained. Developed by Aztec Labs with regular releases and production tooling (nargo, bb).

The on-chain verifier is a Solidity UltraHonk verifier generated by bb write_solidity_verifier. The 2-in/2-out transfer circuit has 6,307 gates and 8 public inputs; verification costs approximately 500,000 gas per shielded transfer.

3.3 Key derivation

Privacy keys derive deterministically from a wallet signature over a frozen message, so no separate seed phrase is needed. HKDF-SHA256 with domain-separated labels expands the signature into a viewing key (X25519) and a spending key. The viewing key can be shared for read-only access — for example auditing — without granting spend authority.

sig          = wallet.personal_sign(DERIVATION_MESSAGE)
viewing_key  = HKDF-SHA256(sig, VIEW_KEY_LABEL)
spending_key = HKDF-SHA256(sig, SPEND_KEY_LABEL)

4 — Consensus

Sanect uses CometBFT with an active set capped at 50 validators. Registrations are unlimited: the top 50 by stake form the consensus set; the rest are wait-listed and rotate in when they pass rank 50. At 50 validators the ⅔ quorum is 34 votes, achievable well under 400 ms on modern infrastructure.

Validators are selected by staked weight (self-bond plus delegations). The lowest validator by total stake is evicted when a higher-staked validator enters. Slashing conditions:

• Double-sign (equivocation): 5% slash, jailing.
• Downtime (missing more than 50% of blocks in a 10,000-block window): 0.01% slash, temporary jailing.

5 — Token economics

SNCT has a genesis supply of 1,000,000,000 minted at TGE across ten allocation buckets. Cosmos Hub-style mint inflation (7–20%, targeting 67% bonded) is layered on top as the ongoing security budget.

Realistic Day-0 circulating supply is approximately 5M SNCT — only genesis validator grants enter the market at launch. There is no VC allocation and no anonymous strategic capital; team allocation is capped at 10%. SNCT has three utility functions: gas, staking and governance.

6 — Security model

The privacy model rests on three cryptographic assumptions:

• Discrete-log hardness on BN254 — the polynomial-commitment scheme used by UltraHonk.
• Collision resistance of Poseidon-2 — commitments, Merkle tree and nullifiers (Aztec’s BN254 parameterisation).
• PRF security of HKDF-SHA256 — spending and viewing key derivation.

The consensus layer is secure while fewer than ⅓ of staked SNCT is Byzantine. The contract layer is subject to standard EVM security assumptions. Third-party audits are underway.

7 — Roadmap

Mainnet launched in June 2026 at chain 7628. Shielded transfers, the Hyperlane bridge to Ethereum (14 assets), DEX, LP farm and .snct name service are live; multi-chain bridge expansion is in progress. See the roadmap.

8 — Bridge architecture

Despite its Cosmos SDK base, Sanect uses Hyperlane — not IBC — as its primary cross-chain protocol, reflecting the network’s EVM-first identity: Hyperlane’s Solidity contracts integrate directly with the EVM layer, avoiding IBC light-client and relayer complexity per connected chain.

The bridge follows a lock-and-mint pattern. Source-chain adapters (HypERC20Collateral) lock tokens on the origin chain; Sanect-side synthetics (HypERC20) mint 1:1 against locked collateral and burn on the way back. A key design choice is a single canonical synthetic per asset: all source-chain adapters for an asset enrol on the same synthetic, so Sanect shows one “USDC” regardless of origin — no chain-suffixed variants and no DEX-pool fragmentation.

Security is enforced by the Interchain Security Module. At launch the network uses a TrustedRelayerIsm backed by the protocol-governance key — a single-operator trust assumption stated plainly. Migration to a MessageIdMultisigIsm with a geographically distributed 2-of-3 validator set is scheduled, after which the bridge’s trust model matches the consensus layer’s. The relayer is a single container running the canonical Hyperlane agent with a whitelist so it processes only Sanect-relevant messages.

Cross-chain delivery takes 1–3 minutes, bounded by source-chain finality and relayer polling. Operator rebalancing of adapter collateral is manual in v1, with an automated rebalancer planned.

9 — DeFi infrastructure

Sanect ships a complete DeFi stack at genesis as protocol-native infrastructure, so liquidity exists from Day 1 and the airdrop programme (Section 10) can measure genuine economic activity across products.

9.1 Decentralised exchange

A Uniswap V2 fork: UniswapV2Factory, UniswapV2Router02 and WSNCT. The AMM uses the constant-product invariant x × y = k. Fifteen pairs are deployed at launch: SNCT-paired pools for price discovery and USDT paired with each other bridged asset.

9.2 LP farm

Liquidity incentives flow through a MasterChef contract emitting 0.1 SNCT per block from the 100M LP-incentives bucket over five years, weighted 30/30/20/20 across SNCT/USDC, SNCT/USDT, SNCT/WETH and SNCT/WBTC. A TVL-tiered per-pool cap (0.0001 → 0.05 SNCT per block from under $1k to over $200k TVL) prevents thin pools from soaking emissions. Cross-asset pairs are excluded from incentives. Target annual emission is 5% of supply; the hard ceiling is 24%, requiring a DAO vote to exceed.

9.3 Name service

An ENS-inspired system with seven components: Registry (namehash → owner/resolver/TTL), PublicResolver, BaseRegistrar (ERC-721 ownership with expiry and renewal), PriceOracle (length-based pricing), SealedBidAuction (Vickrey-style commit–reveal for premium names), Marketplace, and ReverseRegistrar. The TLD node is namehash("snct") = 0x416c9118…2e5f; a Reserved contract holds back protocol-significant names.

10 — Airdrop mechanics

300,000,000 SNCT — 30% of supply, the single largest bucket — is distributed across four phases at Day 180, 270, 360 and 450 (75M each), each claim vesting linearly over 180 days. Points reset every phase; unclaimed tokens revert to Treasury 365 days after a snapshot.

Eligibility is scored by a product points matrix in which every action is time-locked (holding assets in a protocol) or fee-locked (paying real transaction costs), making sybil farming structurally expensive: DEX swap fees and LP duration; MasterChef staking bonus; name registration, auctions, marketplace trades and reverse records; shielded-pool holding and internal sends; bridged-asset holding with a 25% LP bonus; delegation duration; governance votes.

Distribution uses a registered-claim model rather than a Merkle tree: a single AirdropDistributor handles all phases. The operator pre-loads allocations in batches, locks the phase, and users call claim(phase); the vested portion releases via claimVested(phase). Anti-sybil measures are layered: funding-source deduplication, behavioural fingerprinting, referral-graph analysis and economic filtering. Referrals earn 10 points flat plus 10% of every referee’s phase points, uncapped.

11 — Network operations

Validator hardware must sustain sub-second block production: 4+ dedicated cores, 16 GB+ RAM, and NVMe storage — network-attached storage cannot sustain the fsync throughput required; empirically, shared ZFS degraded block time from ~420 ms to ~720 ms with three validators on one pool. Geographic distribution targets Asia ≤ 52% and EU+US ≥ 32% of stake.

Deployment is a single Docker container running sanectd behind Caddy, which routes JSON-RPC (/), CometBFT RPC (/rpc), Cosmos REST (/rest) and WebSocket (/ws). New nodes join via JOIN_NETWORK=true, fetching genesis from a seed and syncing by the fastest available path: an R2-hosted tarball snapshot (1–5 min), CometBFT state sync (2–5 min), or full replay from genesis.

Key management follows a role-EOA model at launch — deployer (retired after Day 0), genesis-treasury, protocol-governance and ops, each hardware-wallet-backed — with migration to 3-of-5 multisig Safes scheduled once Safe contracts are deployed on the chain.

References

1. Buterin, V. (2014). Ethereum White Paper.
2. Kwon, J., Buchman, E. (2016). Cosmos: A Network of Distributed Ledgers.
3. Hopwood, D. et al. (2022). Zcash Protocol Specification. Electric Coin Company.
4. Penumbra Labs (2023). Penumbra Protocol Specification.
5. Aztec Labs. Noir language and Barretenberg documentation.
6. CometBFT (2023). CometBFT Documentation. docs.cometbft.com