Left Icon Right Icon Left Icon Right Icon Right Icon Right Icon Right Icon Right Icon Right Icon

Introduction - What is Inco?

Inco is not a new blockchain. Think of it like a secret envelope you put on top of existing blockchains so important details (like money amounts or private cards) stay hidden — but everyone still sees the envelope exists.

  • Not a chain: integrates with existing blockchains (e.g., Ethereum, Base).
  • Goal: add confidentiality (privacy) without breaking composability.
  • Two main products: Lightning (TEE-based) and Atlas (FHE/MPC-based).
  • For builders (details):
    • Inco is a modular confidentiality layer (an “encryption stack”) you opt into.
    • Design philosophy: same dev tools and languages (Solidity, Hardhat, MetaMask) — minimal friction.
    • Current status: Inco Lightning beta on Base Sepolia testnet; Atlas forthcoming.
Graph 1

Products - Inco Lightning vs Inco Atlas

Lightning = fast secret-keeper using secure hardware. Atlas = secret-keeper using powerful math that can compute while things stay encrypted.

  • Lightning: uses TEEs (secure hardware enclaves), low latency, great for real-time apps.
  • Atlas: uses FHE + MPC, computes on encrypted data, stronger theoretical privacy, higher compute cost today.
  • Lightning use-cases: gaming, high-frequency DeFi, confidential transfers where latency matters.
  • Atlas use-cases: use where cryptographic auditability, post-quantum resistance, or no trusted hardware is preferred.
  • Mixing strategies: Inco combines TEE, FHE, MPC, and ZKPs where appropriate to trade off speed, trust assumptions, and verifiability.
Graph 2

How it works - TEEs, FHE, MPC, ZKPs

This section gives a super-simple snapshot of the main privacy-building blocks Inco uses, then the quick practical trade-offs you’ll care about as a builder (speed, trust, cost, verifiability).

  • TEE: a tiny super-safe room inside a computer where secrets can be used safely.
  • FHE: magic math that lets you do calculations on locked boxes without opening them.
  • MPC: friends compute together without any single friend seeing everyone’s secret.
  • ZKP: prove you did something right without showing how.
  • TEEs: rely on hardware attestation (Intel SGX, ARM TrustZone); provide fast, verifiable compute but require trust in hardware vendor and mitigation of side-channels.
  • FHE: operates on ciphertexts, enables universal encrypted computation; currently slower but improving with batching, packing, and hardware acceleration.
  • MPC: distributes trust; good for decentralization but needs careful anti-collusion design and sometimes higher latency.
  • ZKPs: can complement FHE/TEE by adding succinct verifiability.
Graph 3

Confidential Tokens & cERC20

cERC20 extends the familiar ERC20 idea so token amounts and balances stay secret while token behavior (mint, transfer, burn) still works, plus you can give auditors or regulators permissioned access when needed.

  • Keeps balances & transfers encrypted while preserving ERC20-like operations.
  • Permissions: deployer/authorized viewers can be granted viewing rights for audits or compliance.
  • Developed in collaboration with Circle Research for confidential token frameworks.
  • cERC20 supports mint, burn, transfer semantics but stores amounts encrypted.
  • Design patterns: selective disclosure (grant view keys), operator/viewer roles, audit hooks for regulators.
  • Engineering notes: integrate Inco SDK/library in smart contracts; on-chain state holds ciphertexts and proofs/attestations.
Graph 4

Developer experience & getting started

Inco aims to feel familiar. Use the same EVM toolchain and wallets you already know, then drop in Inco’s encrypted types and SDK to add confidentiality.

  • Languages: Solidity and familiar EVM toolchain supported.
  • Testnet: Base Sepolia (Inco Lightning beta).
  • No new wallet: use the same wallets (MetaMask) and dev tools (Remix, Hardhat).
  • Install Inco Solidity library / SDK and follow local dev flow: write contract → use Inco encrypted types → compile & test.
  • Debugging: test flows on Base Sepolia testnet; use tooling to view authorized decryptions/attestations.
  • Recommended patterns: keep business logic modular (public onchain vs confidential offchain/TEE), limit trusted roles, add audit hooks.
  • Example starter projects: confidential payroll, onchain poker, cERC20 token demo.

Security, limitations & verification model

Every privacy technique has trade-offs. This section summarizes main threats and practical mitigations so you can design the right trust/economics for your app.

  • TEEs: fast, attested, but require trust in hardware vendor and side-channel mitigations.
  • FHE: strong cryptographic guarantees, post-quantum friendly, but currently heavy on compute/time.
  • MPC: distributes trust, requires honest-majority or collusion-resistance economics.
  • Verification: attestation + ZK proofs can establish confidential compute was done correctly.
  • Threats: side-channel attacks, collusion, high latency/cost, faulty attestation chains.
  • Mitigations: layered proofs, redundancy, economic incentives, careful key-management and rotation.
  • Compliance: selective disclosure patterns and audit roles for AML/KYC.
Graph 6

Use cases (short + developer notes)

A compact map of real-world problems Inco unlocks, from private paychecks to private onchain games — with quick notes about which tech often fits best.

  • Consumer & Payments: confidential payroll, P2P payments, streaming payments. (Lightning preferred for low-latency payroll apps.)
  • Trading & TradFi: confidential RWAs, interbank settlement, private trading volumes. (Atlas useful when regulators need cryptographic proofs.)
  • Gaming & NFTs: poker, fog-of-war, hidden NFT attributes and reveals. (Lightning for fast gameplay.)
  • DeFi & Governance: private AMMs, blind auctions, confidential DAO voting. (Hybrid approaches often ideal.)
  • Identity & Healthcare: selective disclosure, encrypted credentials, medical analytics with FHE. (Atlas & MPC shine here.)
  • Supply chain & Storage: encrypt sensitive metadata, program access controls for offchain content. (Combine onchain encrypted keys + offchain storage.)
Graph 7

The four levels of blockchain privacy

For builders: Choose the level per use case. Confidentiality (Inco’s sweet spot) balances composability and compliance better than total anonymity.

  • Transparency — everyone sees everything.
  • Anonymity — amounts visible, identities hidden.
  • Confidentiality — identity visible, amounts hidden (Inco focuses here).
  • Total privacy — nothing visible (privacy chains like Monero).
Graph 8

TEE vs FHE (short comparison)

Quick side-by-side of the two headline approaches so you can pick based on speed, trust, verifiability and future-proofing.

  • TEEs = fast, trust hardware. FHE = mathematically private, trust math + compute cost.
  • Performance: TEE >> FHE (today).
  • Trust model: TEE trusts hardware vendor; FHE trusts crypto assumptions (lattice/LWE).
  • Verifiability: TEEs use attestation; FHE can use deterministic checks and ZK add-ons.
  • Quantum: FHE (lattice-based) is more future-proof.
Graph 9

Practical guide for builders (step-by-step + checklist)

A compact playbook. Take this checklist to go from concept to a live confidential feature on Inco testnet.

  • Choose the privacy level & product (Lightning or Atlas).
  • Prototype: create a minimal Solidity contract using Inco encrypted types.
  • Local test: run unit tests with Inco test harness/emulator.
  • Deploy to Base Sepolia (Lightning beta).
  • Integrate front-end: users sign transactions with MetaMask; Inco SDK handles encryption/attestation.
  • Add selective disclosure: grant viewer keys or audit roles.
  • Security review: threat modeling, attestation verification, test for side-channels and collusion.
  • Performance testing: measure latency/cost; iterate on TEE/FHE hybrid choices.
  • Hybridization: put ultra-low-latency ops in Lightning, heavy analytic ops in Atlas later.
  • Keep public logic onchain; confidential logic offloaded to Inco nodes/TEE/FHE.
  • Governance & audit hooks: encrypted audit logs, role-based decryptors for regulators.
  • UX: make decryption/permissioning frictionless (one-click authorize for auditors).

Glossary (simple definitions)

Quick, snackable definitions you can memorize and use in docs or slides.

  • TEE: a locked room inside a CPU.
  • FHE: math that lets you work on locked boxes.
  • MPC: many people compute together without sharing secrets.
  • ZKP: show you’re telling the truth without showing the secret.
  • cERC20: an ERC20 token that hides amounts.