Cowrie Research

inco

4 min read

Inco

  • Name: Inco
  • Legal entity: Liquidbox Corp. d/b/a Inco
  • URL: https://www.inco.org/
  • Category: confidentiality-middleware company / TEE-compute operator / smart-contract privacy implementation authority
  • Tags: ethereum-ecosystem solana-ecosystem
  • Summary: Inco belongs in companies/, not only projects/, because the practical control surface is not just a confidentiality pattern or a Solidity library. A named operator runs the docs and beta rollout, packages the confidential-compute server path behind Inco Lightning, chooses which chains and environments are actually supported first, and markets the broader full-stack privacy shell developers meet before they reason about the lower-layer architecture. The project note explains the confidentiality middleware; this entity note is for the company boundary that controls the implementation, hosted service path, and rollout defaults around that stack.
  • What it does:
    • Builds and markets Inco as a confidentiality layer for existing blockchains rather than as a new standalone chain
    • Packages Inco Lightning as the current TEE-backed confidential-compute product for EVM and Solana-adjacent developers
    • Maintains the official docs, quickstarts, smart-contract library framing, JavaScript SDK path, and example-driven developer onboarding around the stack
    • Operates the company-facing rollout surface that decides which chains, environments, and product states are actually live versus merely planned
    • Publishes the public GitHub organization where the implementation, demos, templates, and adjacent tooling are concentrated
  • Key claims:
    • The homepage markets Inco as full-stack privacy for blockchains and explicitly says it augments existing chains rather than launching a new one, which is a company-style product-shell framing rather than a neutral protocol spec
    • The docs introduction says Inco Lightning is live on Base Mainnet and Base Sepolia, with Solana Devnet support in beta, which makes supported-environment rollout a real operator decision rather than a generic protocol property
    • The architecture docs say the system has three main components — smart-contract library, confidential compute server, and client-side JavaScript library — which is a strong clue that a named implementation/operator boundary matters alongside the project note
    • The public team page presents Inco as one coordinated organization spanning founder, engineering, protocol, operations, and business roles rather than as a loose neutral standard effort
    • Inco’s privacy policy identifies the operating entity as Liquidbox Corp. d/b/a Inco and says the services are designed for enterprise customers, which is useful because the legal and commercial shell is part of the real dependency surface teams inherit when they use the hosted stack
    • The public GitHub organization concentrates the live implementation and example footprint under one brand, reinforcing that the easiest adoption path still runs through company-maintained code and docs
  • Whitepaper: No separate company whitepaper is the point here. The useful primary materials are the official site, docs, architecture pages, team page, privacy policy, and the public GitHub organization showing where implementation and rollout authority sit.
  • Sources:

Internal linkages

  • Protocol / product note: inco.
  • Nearby operator-shaped privacy / confidential-compute comparison: taceo.
  • Useful implementation-side proving / infra comparison where company packaging matters separately from the project layer: succinct-labs.

Protocol / company boundary

  • Keep projects/inco focused on the confidentiality middleware itself: private data types, encrypted operations, attested decrypt / compute / reveal flows, and the smart-contract-plus-SDK architecture developers integrate.
  • Keep this entity note focused on the named company that ships the docs, operates the rollout and support shell, packages the confidential-compute server path, and decides which environments and workflows are production-ready first.
  • That split matters because the practical question is not only how does Inco work? but also whose hosted implementation, rollout policy, and service boundary do developers depend on when they adopt Inco Lightning?

Control surface

  • Practical leverage sits in confidential-compute server operation, supported-chain rollout, docs and SDK defaults, release stewardship, and the hosted implementation path most teams will trust first.

  • Even if the architecture aims to look like a reusable confidentiality layer, developers currently meet it through one named company shell that decides what is live, documented, and supportable.

  • Treat Inco as a company-run implementation and rollout boundary around privacy middleware, not just a generic privacy for blockchains brand.

  • Last reviewed: 2026-08-11 UTC

Graph View

Backlinks