Inco
- Name: Inco
- URL: https://inco.org/
- Category: confidentiality middleware / confidential smart-contract infrastructure / TEE-backed private-compute layer
- Tags: ethereum-ecosystem solana-ecosystem
- Summary: Inco is a modular confidentiality layer for existing blockchains focused on confidential smart contracts rather than on launching a separate privacy chain. Its current primary sources frame Inco Lightning as a TEE-backed system that adds private data types, encrypted operations, programmable access control, and attested decryption / compute flows to existing developer stacks through a smart-contract library, an offchain confidential-compute service, and a JavaScript SDK. Keep this note on the middleware and architecture itself; use inco when the sharper question is who operates the rollout, packages the hosted compute path, controls supported-environment timing, and owns the enterprise-facing implementation shell around that stack.
- What it does:
- Lets developers build confidential smart contracts using private data types, encrypted operations, and programmable access-control rules without requiring a new chain or wallet
- Uses Trusted Execution Environments (TEEs) for confidential compute in Inco Lightning, with attested decrypt, attested compute, and attested reveal flows documented for onchain-verifiable usage
- Splits the system into three main architectural components: a smart-contract library, a confidential compute server, and a client-side JavaScript library
- Provides developer onboarding through quickstart templates, JavaScript SDK docs, and example repos for EVM and Solana-oriented workflows
- Markets support for private payments, confidential tokens, private DeFi primitives, games, and other privacy-preserving application patterns
- Key claims:
- The official site describes Inco as “full-stack privacy for blockchains” and says it brings privacy to existing tools across EVM and SVM environments
- The docs introduction says Inco is a confidentiality layer for existing blockchains and that Inco Lightning requires “No new chain, no new wallet”
- The docs currently note that Inco Lightning is available on Base Sepolia in beta testnet, which is an important reality check against the broader compatibility language on the homepage
- The architecture docs say Inco follows a modular approach similar to SSL/TLS for internet protocols and identify three core components: smart-contract library, confidential compute server, and client-side JavaScript library
- The decryption docs define three attested flows — Attested Decrypt, Attested Compute, and Attested Reveal — as the main mechanism for using encrypted state and verified plaintext/results
- The homepage claims the system is non-custodial, verifiable end-to-end, and designed so operator theft is impossible, while also advertising a force-exit path
- The public GitHub organization reinforces that Inco’s real operating surface includes SDKs, starter templates, and example apps, not just a marketing site or research concept
- Whitepaper: No public standalone whitepaper was found during this pass. In fact, the architecture overview explicitly says “Whitepaper coming soon!” The strongest primary materials were the official site, docs portal, docs index, architecture and decryption pages, quickstart/SDK docs, and public GitHub organization; see
../whitepapers/inco-primary-sources-2026-04-26.md. - Sources:
- https://inco.org/
- https://docs.inco.org/home.md
- https://docs.inco.org/llms.txt
- https://docs.inco.org/introduction.md
- https://docs.inco.org/architecture/overview.md
- https://docs.inco.org/architecture/decryption-mechanisms.md
- https://docs.inco.org/js-sdk.md
- https://docs.inco.org/quickstart.md
- https://github.com/Inco-fhevm
Internal linkages
Protocol / company boundary
- Keep
projects/incoon the confidentiality middleware itself: private data types, encrypted operations, attested decrypt / compute / reveal flows, and the smart-contract-plus-SDK architecture developers integrate. - Use inco when the real question is who ships the docs, operates the hosted confidential-compute path, chooses which chains and environments are actually live first, and packages the enterprise-facing rollout shell.
- That split matters because a confidentiality pattern can be conceptually reusable while the implementation and support path remains company-shaped.
Control surface
-
At the project layer, the leverage sits in data-type semantics, access-control design, attestation flow, and how the middleware composes with existing chains.
-
But do not flatten the rollout and hosted-service dependency into the same note: the current live path still runs through a named operator boundary captured in inco.
-
Last reviewed: 2026-08-11 UTC