What Is Confidential Composability?

While transparency is a key strength of blockchains, it’s also what’s holding them back from achieving mainstream adoption. While being able to see the details of a transaction onchain enhances trust and minimizes counterparty risk, there are many use cases that require information to be kept hidden from the public eye.

There are multiple ways of achieving this, from private chains to zero-knowledge proofs. Each approach has its strengths and trade-offs. At Inco, we’re confident that our encryption-based approach strikes the optimum balance. As a confidentiality layer that works to complement existing blockchains with confidentiality, Inco is flexible and secure while retaining one of blockchains’ superpowers: composability.

While commitment-based approaches and private chains achieve confidentiality, they sacrifice composability. With Inco, developers can build apps on blockchains without the restrictions imposed by having to run proofs or move to a siloed chain that fragments liquidity. Developers can simply build as they would do with any EVM chain with established standards, and leverage Inco’s confidentiality layer to keep specific onchain data confidential as they wish.

What Is Confidential Composability?

In crypto, composability refers to the ability of different protocols, smart contracts, and dApps to interact and combine with each other seamlessly, creating new applications and services. You might think of a lending protocol integrated permissionlessly with a decentralized exchange (DEX), meaning users can borrow and trade to attempt to realize gains with minimal user experience or interoperability overhead. 

But because blockchains are transparent, this “money Legos” approach exposes what users do across the composable apps they use. And when they use confidentiality tools, they sacrifice composability: private chains require bridging, which can introduce security risks and latency concerns and fragment liquidity. Commitment-based approaches like Zero-Knowledge Proofs (ZKPs) often sacrifice composability by relying on fixed circuits, rigid constraints, and lack of runtime flexibility—making it hard to compose them with other contracts without major rewrites or pre-coordination.

Let’s explore the benefits of confidential composability further by looking at a few use cases.

Confidential Composability Use Cases

Confidential Transfers

Enabling confidential transfers has been one of the major problems in onchain payments because of the transparent nature of blockchains. There have been several attempts, such as ZCash and Zether, to allow users to make private transfers, but these leverage zero-knowledge proofs or other commitment-based methods to achieve confidentiality. 

Inco enables confidential ERC20 tokens by utilizing encrypted types. By modifying the existing token contracts slightly, it is now possible to build confidential tokens that are totally composable.

This makes it possible to build things like payroll systems, private payments in DAOs, or personal budgeting tools that run onchain without leaking sensitive data—not to mention a world of DeFi applications—and these apps can be built composably with conventional smart contracts, opening the possibility of linking them together.

For more details, check our collaborative work with Circle Research on Confidential ERC20.

Private Auctions

While newer ZK architectures aim to improve composability, they still often require custom circuits or external services to coordinate private interactions, which limits plug-and-play integrations.

Inco makes private bidding just another smart contract use case. The only thing developers need to do is rewrite an auction contract so that it works with encrypted types and methods. After deploying the private auction contract, it is easy to plug it into existing onchain marketplace infrastructure without needing to redesign the logic. For instance, the builder can integrate the auction contract into an NFT marketplace contract that makes contract calls to the auction contract so that items can be sold in auctions instead of only direct purchases. That’s composable confidentiality in action.

Onchain Games

Games that need private states, like poker, for example, usually run on centralized servers, and most attempts to bring them onchain use ZK-based game building tools or external trust assumptions. This either requires technical commit-reveal cycles interrupting gameplay or reintroducing a trusted intermediary party.

Inco makes it possible to consider private states as just another variable in Solidity. Any Solidity developer can write onchain games with private states by using the relevant encrypted types and methods. Another benefit of this is that they don’t have to sacrifice composability—they can easily integrate another contract, like a confidential token, into the game logic.

Private Governance and Confidential Voting

Similar to other use cases, private voting also requires composability for several important reasons. First, composability helps eliminate external trust assumptions by allowing cryptographic components—such as identity verification, vote encryption, and tallying—to be combined in a single system. Second, composability reduces computational overhead by enabling the reuse of modular, optimized primitives rather than having to rebuild or duplicate complex logic in every voting instance.

By using Inco, it is straightforward to build an onchain private voting system that preserves the confidentiality of voters while not sacrificing composability, as an onchain private voting contract can easily be integrated into another contract; or another contract, like a confidential token contract, can be integrated into the voting system.

Developer Experience

Build Like You Would With the EVM

One of the biggest benefits of Inco’s approach is that you don’t have to change how you build. There’s no need to learn a new language, design complex ZK circuits, or work around a whole new infrastructure. If you know how to build on an EVM chain, you already know how to build with Inco.

You write Solidity, you deploy to an EVM-compatible network, and you use the same standards, like ERC20 or ERC721, that you’re already familiar with. The only difference is: now you have encrypted types. You can use them like you would any other variable, except they keep the data private.

What really brings the advantage is the composability. With commitment-based approaches like ZK rollups or custom privacy layers, developers often need to commit to specific structures or fixed parameters. That limits flexibility and breaks interoperability, which means that you can't easily plug one contract into another or compose new logic without major rewrites or added trust assumptions. Inco’s confidentiality layer means you can build money lego DeFi apps with exactly the same tools as you would normally, but the contracts can include private types.

With Inco, encrypted types behave like native types. That means confidential components can be composed just like any other contract on the EVM without needing to rebuild logic to make components talk to each other.

Start Building Today

Composable confidentiality means developers don’t have to trade off privacy for usability anymore. With Inco, privacy becomes just another tool in your toolbox—something you can reach for when the use case calls for it.

It’s super easy to get started. Just drop in the Inco library, and start building use cases that you’d never have been able to create before..

Want to see what you can build with confidential building blocks? Explore the Inco docs.