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 Plonk-family 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 that integrates two execution environments: an EVM (Ethereum Virtual Machine) 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; developers can deploy existing Solidity contracts without modification.

2.2 Cosmos SDK base

The consensus and state layer is a standard Cosmos SDK application chain running CometBFT (formerly Tendermint) Byzantine fault-tolerant consensus. This provides deterministic finality within one block (no probabilistic finality), IBC compatibility for cross-chain messaging, and a native staking and governance module. 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. Sanect exposes them at the following addresses:

0x0000000000000000000000000000000000000800  // staking
0x0000000000000000000000000000000000000801  // distribution (rewards)
0x0000000000000000000000000000000000000802  // IBC transfer
0x0000000000000000000000000000000000000803  // reserved
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 (which masks state transitions), 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 note 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 implemented in Noir — Aztec’s domain-specific language for zero-knowledge proofs — and compiled to Plonk-family zk-SNARKs (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, no per-circuit ceremony, eliminating the “toxic waste” problem of Groth16.
• Browser proving. Noir compiles to wasm; client-side proof generation takes roughly 2–3 seconds on a standard laptop — no server-side prover is needed.
• Actively maintained. Developed by Aztec Labs with regular releases, an active community and production-grade tooling (nargo, bb).

The on-chain verifier is a Solidity UltraHonk verifier contract 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 are derived deterministically from a wallet-signed message, avoiding a separate seed phrase. 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: anyone can register, the top 50 by stake form the active consensus set, and the rest are wait-listed and rotate in when they pass rank 50. At 50 validators the ⅔ quorum is 34 votes, achievable in well under 400 ms on modern network infrastructure.

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

• Double-sign (equivocation): 5% slash, permanent 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 a 67% bonded ratio) is layered on top as the ongoing validator security budget. Distribution:

Realistic Day-0 circulating supply is approximately 5M SNCT — only the genesis validator grants enter the open market at launch. There is no VC allocation, no anonymous strategic capital, and team allocation is capped at 10% (sub-industry norm). SNCT has three utility functions: gas (all transactions pay fees in SNCT), staking (validators and delegators bond SNCT to secure the chain), and governance (bonded SNCT confers voting weight on on-chain proposals).

6 — Security model

The security of the Sanect privacy model rests on three cryptographic assumptions:

• Discrete-log hardness on BN254 — the security of the polynomial-commitment scheme used by Barretenberg’s UltraHonk prover.
• Collision resistance of the Poseidon-2 hash — used for note commitments, Merkle tree construction and nullifier computation (Aztec’s BN254 parameterisation).
• PRF security of HKDF-SHA256 — used for spending and viewing key derivation from wallet signatures.

The consensus layer is secure as long as fewer than ⅓ of staked SNCT is held by Byzantine validators. The smart-contract layer is subject to standard EVM security assumptions. Third-party security audits are underway.

7 — Roadmap

See the roadmap page for the current development status. Mainnet launched on 22 June 2026 at chain ID 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.

8 — Bridge architecture

Despite its Cosmos SDK base, Sanect uses Hyperlane — not IBC — as its primary cross-chain protocol, This decision reflects the network’s EVM-first identity: Hyperlane’s Solidity-native contracts integrate directly with the EVM execution layer, avoiding the Cosmos-side IBC light-client complexity that would otherwise require maintaining relayer infrastructure for every connected chain.

The bridge architecture follows a lock-and-mint pattern:

• Source-chain adapters (HypERC20Collateral) lock tokens on the origin chain (for example Ethereum mainnet). Each adapter holds the real ERC-20 tokens as collateral.
• Sanect-side synthetics (HypERC20) are minted 1:1 against locked collateral. When a user bridges back, synthetics are burned and collateral is released on the source chain.

A critical design choice: single canonical synthetic per asset. All source-chain adapters for a given asset (Ethereum, BSC, Arbitrum, etc.) enrol as remote routers on the same Sanect-side synthetic contract. Sanect therefore shows one “USDC” token regardless of which chain a user bridged from — eliminating the DEX-pool fragmentation and user confusion caused by chain-suffixed variants (for example USDC.eth vs USDC.bsc).

Security is enforced by the Interchain Security Module (ISM). At launch the network uses a TrustedRelayerIsm backed by the protocol-governance key. This is a pragmatic Day-0 posture — the trust assumption is equivalent to running a single-operator bridge, stated plainly. Migration to a MessageIdMultisigIsm with a multi-validator set (2-of-3 threshold, geographically distributed) is scheduled, at which point the bridge’s trust model matches the consensus layer’s BFT guarantees.

The relayer is a single Docker container running the canonical Hyperlane agent image, watching both Sanect and connected chains. A whitelist filter ensures it only processes Sanect-relevant messages, avoiding the cost of indexing the entire Hyperlane message backlog on high-traffic chains like Ethereum mainnet.

At launch, 14 assets are bridged from Ethereum mainnet:

Deploying all 14 assets cost roughly $30 in Ethereum gas in total. Cross-chain delivery takes 1–3 minutes, bounded by source-chain finality and relayer polling interval. Operator rebalancing (ensuring each source-chain adapter has sufficient collateral for withdrawals) is manual in v1, with an automated rebalancer planned for v2.

9 — DeFi infrastructure

Sanect ships a complete DeFi stack at genesis — not as third-party deployments, but as protocol-native infrastructure. This ensures liquidity exists from Day 1 and that the airdrop programme (Section 10) can measure genuine on-chain economic activity across multiple products.

9.1 Decentralised exchange

The DEX is a Uniswap V2 fork of three core contracts: UniswapV2Factory (pair creation), UniswapV2Router02 (swap routing and liquidity management) and WSNCT (wrapped native token for ERC-20 compatibility). The AMM uses the standard constant-product formula x × y = k, where reserves adjust automatically to maintain the invariant after each swap.

At launch, 15 trading pairs are deployed on the factory. These include SNCT-paired pools for price discovery (USDC/WSNCT, USDT/WSNCT, WETH/WSNCT, WBTC/WSNCT) and cross-asset pairs for bridged token trading (USDT paired with each of the 13 other bridged assets). The swap UI supports an approval-before-swap flow, balance checks and MAX buttons — standard DEX UX any DeFi user will recognise.

9.2 LP farm

Liquidity incentives are distributed through a MasterChef contract emitting 0.1 SNCT per block (~0.79% of supply annualised at the current block rate). The LP-incentives bucket allocates 100M SNCT over 5 years. Four SNCT-paired pools receive emissions, weighted to prioritise stablecoin depth:

To prevent emission dilution at low TVL, a TVL-tiered per-pool emission cap governs the maximum reward rate regardless of allocPoint share:

Cross-asset pairs (for example USDT/USDC) exist as factory pairs for trading convenience but are explicitly excluded from the LP incentive program. Enforcement is soft governance in v1 (protocol-governance review plus UI warnings); an on-chain TvlCapWrapper is planned for Phase 2 hardening. The target annual emission is 5% of supply, with a hard ceiling at 24% requiring a DAO vote to exceed.

9.3 Name service

The .snct name service is an ENS-inspired domain system providing human-readable addresses on Sanect. The contract architecture consists of seven components:

• Registry: the root ownership ledger mapping namehash nodes to owner/resolver/TTL records.
• PublicResolver: stores address records, text records, content hashes and ABI data for each name.
• BaseRegistrar: ERC-721 NFT representing ownership of second-level .snct names, with expiry and renewal logic.
• PriceOracle: length-based pricing (shorter names cost more, incentivising efficient namespace usage).
• SealedBidAuction: Vickrey-style sealed-bid auctions for premium names — users commit a blinded bid hash, then reveal in a second phase. Highest bidder wins at the second-highest price.
• Marketplace: secondary market for name trading with protocol fee capture.
• ReverseRegistrar: lets addresses set a primary .snct name for reverse resolution (address-to-name lookup).

The TLD node is computed as namehash("snct") = 0x416c9118…2e5f, matching the ENS namehash algorithm applied to the snct label. All contracts are deployed at genesis alongside a Reserved contract that holds back protocol-significant names from open registration.

10 — Airdrop mechanics

300,000,000 SNCT (30% of total supply) is allocated to an airdrop programme distributed across four phases. This is the single largest allocation bucket — larger than Treasury, larger than Team — reflecting the protocol’s thesis that token distribution should reward genuine product usage, not early capital access.

Points reset each phase (anti-mercenary — no advantage to farming early and leaving). Unclaimed tokens more than 365 days post-snapshot revert to Treasury.

Eligibility is determined by a 14-product points matrix that scores on-chain activity across every Sanect product. Each action is either time-locked (holding assets in a protocol) or fee-locked (paying real transaction costs), making sybil farming structurally expensive. The product categories are:

• DEX: swap fee contribution, order-book volume and LP holding duration
• LP Farm: MasterChef staking bonus on top of LP holding
• Name Service: registration (by year), auction wins, marketplace trades, reverse-record setup
• Shielded Pool: holding duration in the privacy pool and internal sends
• Bridge: bridged-in asset holding duration, plus a 25% bonus on LP positions containing bridged assets
• Native staking: delegation holding duration
• Governance: voting participation

The distribution uses a registered-claim model, not a Merkle tree. A single AirdropDistributor.sol contract handles all four phases. Before each phase opens, the operator pre-loads per-user allocations via batch transactions (~500 users per transaction), then calls lockPhase(). Users connect their wallet, sign a verification message and call claim(phase). The liquid portion lands immediately; the vested portion is registered on-chain and released linearly over 180 days via claimVested(phase). This model was chosen over Merkle proofs for a simpler audit surface and better lost-key recovery UX.

Anti-sybil measures are layered rather than relying on a single heuristic:

• Funding-source deduplication: if 50+ referees fund from the same source within 1 hour, attribution is voided
• Behavioural fingerprinting: clustering wallets by activity patterns across products
• Referral-graph analysis: detecting circular or self-referral structures
• Economic filtering: every points-eligible action is cash-flow negative for a farmer on Day 1, redeemed only by vest payoff over 6 months

The referral system awards 10 points flat per successful referral plus 10% of every referee’s phase points, every phase. A successful referral requires five criteria: the referee bridged at least $50 or used 3+ Sanect products; the referee wallet existed before the referral was claimed; each wallet can only be referred once; the referrer has at least 100 own points before commission unlocks; and funding-source dedup passes. There is no per-wallet cap and no per-referrer cap — real reach earns real rewards.

11 — Network operations

Running a Sanect validator requires hardware that can sustain sub-second block production under CometBFT. The minimum requirements reflect the performance floor for consistent participation in the active validator set:

• CPU: 4+ cores (dedicated, not shared or burstable)
• Memory: 16 GB+ RAM (IAVL tree caching is memory-intensive under sustained block production)
• Storage: NVMe SSD mandatory — spinning disks and network-attached storage (including cloud ZFS volumes) cannot sustain the fsync throughput required for consistent 400 ms blocks. Empirically, shared ZFS on Railway degraded block time from ~420 ms to ~720 ms with 3+ validators on the same pool.
• Network: 100 Mbps+ with low-latency connectivity to peer validators. Geographic distribution per the Variant A topology targets Asia ≤ 52% and EU+US ≥ 32% of stake to prevent regional jurisdiction concentration.

Node deployment is Docker-based: a single container runs the sanectd binary behind a Caddy reverse proxy. Caddy provides a single-port HTTP front that routes EVM JSON-RPC (/), CometBFT RPC (/rpc), Cosmos REST (/rest) and WebSocket (/ws) traffic to the appropriate internal ports. TLS termination is handled by Caddy’s built-in ACME integration or by the hosting provider’s edge proxy.

New nodes join via JOIN_NETWORK=true mode, which fetches genesis from a seed node, configures persistent peers and syncs by the fastest available path. Three strategies are available, in order of speed:

• Tarball snapshot (~1–5 min): downloads a compressed snapshot of the chain’s data/ directory from Cloudflare R2 object storage. Snapshots are published every 6 hours by streaming tar | lz4 directly to R2 — no local staging required. A LATEST.json manifest tracks the most recent snapshot height and URL.
• State sync (~2–5 min): CometBFT’s native state sync fetches a snapshot at tip − 2000 via P2P, configured automatically by the entrypoint.
• Block replay from genesis (hours to days): full historical replay as a fallback when neither snapshot method succeeds.

Monitoring covers four dimensions: block-time tracking (target 400 ms ± 20%), validator uptime (signed blocks per window), consensus participation rate (missed rounds trigger alerts before the jailing threshold) and chain-tip lag for archive/RPC nodes. The staking dApp exposes a /network/nodes dashboard where validators self-register via heartbeat, giving real-time visibility into the validator set’s health.

Key management follows a role-EOA model at launch, with four distinct keys: deployer (retired after Day 0), genesis-treasury, protocol-governance and ops. Each is hardware-wallet-backed. The protocol-governance key owns the ShieldedPool and the future AirdropDistributor. Migration to on-chain 3-of-5 multisig Safes is scheduled once Safe contracts are deployed on the chain — Safe Global does not natively support new chains at launch, so Safe contracts must be deployed manually first.

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. Bowe, S. et al. (2022). Halo2 Book. Zcash Foundation. zcash.github.io/halo2 ↗
5. Penumbra Labs (2023). Penumbra Protocol Specification.
6. Aztec Labs. Noir language and Barretenberg documentation.
7. CometBFT (2023). CometBFT Documentation. docs.cometbft.com