Skip to main content

2 posts tagged with "Cryptography"

View All Tags

Sui-Backed MPC Network Ika – Comprehensive Technical and Investment Evaluation

· 39 min read

Introduction

Ika is a parallel Multi-Party Computation (MPC) network strategically backed by the Sui Foundation. Formerly known as dWallet Network, Ika is designed to enable zero-trust, cross-chain interoperability at high speed and scale. It allows smart contracts (especially on the Sui blockchain) to securely control and coordinate assets on other blockchains without traditional bridges. This report provides a deep dive into Ika’s technical architecture and cryptographic design from a founder’s perspective, as well as a business and investment analysis covering team, funding, tokenomics, adoption, and competition. A summary comparison table of Ika versus other MPC-based networks (Lit Protocol, Threshold Network, and Zama) is also included for context.

Ika Network

Technical Architecture and Features (Founder’s Perspective)

Architecture and Cryptographic Primitives

Ika’s core innovation is a novel “2PC-MPC” cryptographic scheme – a two-party computation within a multi-party computation framework. In simple terms, the signing process always involves two parties: (1) the user and (2) the Ika network. The user retains a private key share, and the network – composed of many independent nodes – holds the other share. A signature can only be produced with participation from both, ensuring the network alone can never forge a signature without the user. The network side isn’t a single entity but a distributed MPC among N validators that collectively act as the second party. A threshold of at least two-thirds of these nodes must agree (akin to Byzantine Fault Tolerance consensus) to generate the network’s share of the signature. This nested MPC structure (user + network) makes Ika non-collusive: even if all Ika nodes collude, they cannot steal user assets because the user’s participation (their key share) is always cryptographically required. In other words, Ika enables “zero-trust” security, upholding decentralization and user ownership principles of Web3 – no single entity or small group can unilaterally compromise assets.

Figure: Schematic of Ika’s 2PC-MPC architecture – the user acts as one party (holding a private key share) and the Ika network of N validators forms the other party via an MPC threshold protocol (t-out-of-N). This guarantees that both the user and a supermajority of decentralized nodes must cooperate to produce a valid signature.

Technically, Ika is implemented as a standalone blockchain network forked from the Sui codebase. It runs its own instance of Sui’s high-performance consensus engine (Mysticeti, a DAG-based BFT protocol) to coordinate the MPC nodes. Notably, Ika’s version of Sui has smart contracts disabled (Ika’s chain exists solely to run the MPC protocol) and includes custom modules for the 2PC-MPC signing algorithm. Mysticeti provides a reliable broadcast channel among the nodes, replacing the complex mesh of peer-to-peer messages that traditional MPC protocols use. By leveraging a DAG-based consensus for communication, Ika avoids the exponential communication overhead of earlier threshold signing schemes, which required each of n parties to send messages to all others. Instead, Ika’s nodes broadcast messages via the consensus, achieving linear communication complexity O(n), and using batching and aggregation techniques to keep per-node costs almost constant even as N grows large. This represents a significant breakthrough in threshold cryptography: the Ika team replaced point-to-point “unicast” communication with efficient broadcast and aggregation, enabling the protocol to support hundreds or thousands of participants without slowing down.

Zero-knowledge integrations: At present, Ika’s security is achieved through threshold cryptography and BFT consensus rather than explicit zero-knowledge proofs. The system does not rely on zk-SNARKs or zk-STARKs in its core signing process. However, Ika uses on-chain state proofs (light client proofs) to verify events from other chains, which is a form of cryptographic verification (e.g. verifying Merkle proofs of block headers or state). The design leaves room for integrating zero-knowledge techniques in the future – for example, to validate cross-chain state or conditions without revealing sensitive data – but as of 2025 no specific zk-SNARK module is part of Ika’s published architecture. The emphasis is instead on the “zero-trust” principle (meaning no trust assumptions) via the 2PC-MPC scheme, rather than zero-knowledge proof systems.

Performance and Scalability

A primary goal of Ika is to overcome the performance bottlenecks of prior MPC networks. Legacy threshold signature protocols (like Lindell’s 2PC ECDSA or GG20) struggled to support more than a handful of participants, often taking many seconds or minutes to produce a single signature. In contrast, Ika’s optimized protocol achieves sub-second latency for signing and can handle a very high throughput of signature requests in parallel. Benchmark claims indicate Ika can scale to around 10,000 signatures per second while maintaining security across a large node cluster. This is possible thanks to the aforementioned linear communication and heavy use of batching: many signatures can be generated concurrently by the network in one round of protocol, dramatically amortizing costs. According to the team, Ika can be “10,000× faster” than existing MPC networks under load. In practical terms, this means real-time, high-frequency transactions (such as trading or cross-chain DeFi operations) can be supported without the usual delays of threshold signing. Latency is on the order of sub-second finality, meaning a signature (and the corresponding cross-chain operation) can be completed almost instantly after a user’s request.

Equally important, Ika does this while scaling out the number of signers to enhance decentralization. Traditional MPC setups often used a fixed committee of maybe 10–20 nodes to avoid performance collapse. Ika’s architecture can expand to hundreds or even thousands of validators participating in the signing process without significant slowdown. This massive decentralization improves security (harder for an attacker to corrupt a majority) and network robustness. The underlying consensus is Byzantine fault tolerant, so the network can tolerate up to one-third of nodes being compromised or offline and still function correctly. In any given signing operation, only a threshold t-of-N of nodes (e.g. 67% of N) need to actively participate; by design, if too many nodes are down, the signature might be delayed, but the system is engineered to handle typical failure scenarios gracefully (similar to a blockchain’s consensus liveness and safety properties). In summary, Ika achieves both high throughput and high validator count, a combination that sets it apart from earlier MPC solutions that had to trade off decentralization for speed.

Developer Tooling and Integration

The Ika network is built to be developer-friendly, especially for those already building on Sui. Developers do not write smart contracts on Ika itself (since Ika’s chain doesn’t run user-defined contracts), but instead interact with Ika from other chains. For example, a Sui Move contract can invoke Ika’s functionality to sign transactions on external chains. To facilitate this, Ika provides robust tooling and SDKs:

  • TypeScript SDK: Ika offers a TypeScript SDK (Node.js library) that mirrors the style of the Sui SDK. This SDK allows builders to create and manage dWallets (decentralized wallets) and issue signing requests to Ika from their applications. Using the TS SDK, developers can generate keypairs, register user shares, and call Ika’s RPC to coordinate threshold signatures – all with familiar patterns from Sui’s API. The SDK abstracts away the complexity of the MPC protocol, making it as simple as calling a function to request (for example) a Bitcoin transaction signature, given the appropriate context and user approval.

  • CLI and Local Network: For more direct interaction, a command-line interface (CLI) called dWallet CLI is available. Developers can run a local Ika node or even a local test network by forking the open-source repository. This is valuable for testing and integration in a development environment. The documentation guides through setting up a local devnet, getting testnet tokens (DWLT – the testnet token), and creating a first dWallet address.

  • Documentation and Examples: Ika’s docs include step-by-step tutorials for common scenarios, such as “Your First dWallet”. These show how to establish a dWallet that corresponds to an address on another chain (e.g., a Bitcoin address controlled by Ika’s keys), how to encrypt the user’s key share for safekeeping, and how to initiate cross-chain transactions. Example code covers use cases like transferring BTC via a Sui smart contract call, or scheduling future transactions (a feature Ika supports whereby a transaction can be pre-signed under certain conditions).

  • Sui Integration (Light Clients): Out-of-the-box, Ika is tightly integrated with the Sui blockchain. The Ika network runs a Sui light client internally to trustlessly read Sui on-chain data. This means a Sui smart contract can emit an event or call that Ika will recognize (via a state proof) as a trigger to perform an action. For instance, a Sui contract might instruct Ika: “when event X occurs, sign and broadcast a transaction on Ethereum”. Ika nodes will verify the Sui event using the light client proof and then collectively produce the signature for the Ethereum transaction. The signed payload can then be delivered to the target chain (possibly by an off-chain relayer or by the user) to execute the desired action. Currently, Sui is the first fully supported controller chain (given Ika’s origins on Sui), but the architecture is multi-chain by design. Support for other chains’ state proofs and integrations are on the roadmap – for example, the team has mentioned extending Ika to work with rollups in the Polygon Avail ecosystem (providing dWallet capabilities on rollups with Avail as a data layer) and other Layer-1s in the future.

  • Supported Crypto Algorithms: Ika’s network can generate keys/signatures for virtually any blockchain’s signature scheme. Initially it supports ECDSA (the elliptic curve algorithm used by Bitcoin, Ethereum’s ECDSA accounts, BNB Chain, etc.). In the near term, it’s planned to support EdDSA (Ed25519, used by chains like Solana and some Cosmos chains) and Schnorr signatures (e.g. Bitcoin Taproot’s Schnorr keys). This broad support means an Ika dWallet can have an address on Bitcoin, an address on Ethereum, on Solana, and so on – all controlled by the same underlying distributed key. Developers on Sui or other platforms can thus integrate any of these chains into their dApps through one unified framework (Ika), instead of dealing with chain-specific bridges or custodians.

In summary, Ika offers a developer experience similar to interacting with a blockchain node or wallet, abstracting away the heavy cryptography. Whether via the TypeScript SDK or directly through Move contracts and light clients, it strives to make cross-chain logic “plug-and-play” for builders.

Security, Decentralization, and Fault Tolerance

Security is paramount in Ika’s design. The zero-trust model means that no user has to trust the Ika network with unilateral control of assets at any point. If a user creates a dWallet (say a BTC address managed by Ika), that address’s private key is never held by any single party – not even the user alone. Instead, the user holds a secret share and the network collectively holds the other share. Both are required to sign any transaction. Thus, even if the worst-case scenario occurred (e.g. many Ika nodes were compromised by an attacker), they still could not move funds without the user’s secret key share. This property addresses a major risk in conventional bridges, where a quorum of validators could collude to steal locked assets. Ika eliminates that risk by fundamentally changing the access structure (the threshold is set such that the network alone is never enough – the threshold effectively includes the user). In the literature, this is a new paradigm: a non-collusive MPC network where the asset owner remains part of the signing quorum by design.

On the network side, Ika uses a delegated Proof-of-Stake model (inherited from Sui’s design) for selecting and incentivizing validators. IKA token holders can delegate stake to validator nodes; the top validators (weighted by stake) become the authorities for an epoch, and are Byzantine-fault-tolerant (2/3 honest) in each epoch. This means the system assumes <33% of stake is malicious to maintain safety. If a validator misbehaves (e.g. tries to produce an incorrect signature share or censor transactions), the consensus and MPC protocol will detect it – incorrect signature shares can be identified (they won’t combine to a valid signature), and a malicious node can be logged and potentially slashed or removed in future epochs. Meanwhile, liveness is maintained as long as enough nodes (>67%) participate; the consensus can continue to finalize operations even if many nodes crash or go offline unexpectedly. This fault tolerance ensures the service is robust – no single point of failure exists since hundreds of independent operators in different jurisdictions are participating. Decentralization is further reinforced by the sheer number of participants: Ika does not limit itself to a fixed small committee, so it can onboard more validators to increase security without sacrificing much performance. In fact, Ika’s protocol was explicitly designed to “transcend the node limit of MPC networks” and allow massive decentralization.

Finally, the Ika team has subjected their cryptography to external review. They published a comprehensive whitepaper in 2024 detailing the 2PC-MPC protocol, and they have undergone at least one third-party security audit so far. For example, in June 2024, an audit by Symbolic Software examined Ika’s Rust implementation of the 2PC-MPC protocol and related crypto libraries. The audit would have focused on validating the correctness of the cryptographic protocols (ensuring no flaw in the threshold ECDSA scheme, key generation, or share aggregation) and checking for potential vulnerabilities. The codebase is open-source (under the dWallet Labs GitHub), allowing the community to inspect and contribute to its security. As of the alpha testnet stage, the team also cautioned that the software was still experimental and not yet production-audited, but ongoing audits and security improvements were a top priority prior to mainnet launch. In summary, Ika’s security model is a combination of provable cryptographic guarantees (from threshold schemes) and blockchain-grade decentralization (from the PoS consensus and large validator set), reviewed by experts, to provide strong assurances against both external attackers and insider collusion.

Compatibility and Ecosystem Interoperability

Ika is purpose-built to be an interoperability layer, initially for Sui but extensible to many ecosystems. On day one, its closest integration is with the Sui blockchain: it effectively acts as an add-on module to Sui, empowering Sui dApps with multi-chain capabilities. This tight alignment is by design – Sui’s Move contracts and object-centric model make it a good “controller” for Ika’s dWallets. For instance, a Sui DeFi application can use Ika to pull liquidity from Ethereum or Bitcoin on the fly, making Sui a hub for multi-chain liquidity. Sui Foundation’s support for Ika indicates a strategy to position Sui as “the base chain for every chain”, leveraging Ika to connect to external assets. In practice, when Ika mainnet is live, a Sui builder might create a Move contract that, say, accepts BTC deposits: behind the scenes, that contract would create a Bitcoin dWallet (an address) via Ika and issue instructions to move BTC when needed. The end user experiences this as if Bitcoin is just another asset managed within the Sui app, even though the BTC stays native on Bitcoin until a valid threshold-signed transaction moves it.

Beyond Sui, Ika’s architecture supports other Layer-1 blockchains, Layer-2s, and even off-chain systems. The network can host multiple light clients concurrently, so it can validate state from Ethereum, Solana, Avalanche, or others – enabling smart contracts on those chains (or their users) to also leverage Ika’s MPC network. While such capabilities might roll out gradually, the design goal is chain-agnostic. In the interim, even without deep on-chain integration, Ika can be used in a more manual way: for example, an application on Ethereum could call an Ika API (via an Oracle or off-chain service) to request a signature for an Ethereum tx or a message. Because Ika supports ECDSA, it could even be used to manage an Ethereum account’s key in a decentralized way, similarly to how Lit Protocol’s PKPs work (we discuss Lit later). Ika has also showcased use cases like controlling Bitcoin on rollups – an example being integrating with the Polygon Avail framework to allow rollup users to manage BTC without trusting a centralized custodian. This suggests Ika may collaborate with various ecosystems (Polygon/Avail, Celestia rollups, etc.) as a provider of decentralized key infrastructure.

In summary, from a technical standpoint Ika is compatible with any system that relies on digital signatures – which is essentially all blockchains. Its initial deployment on Sui is just the beginning; the long-term vision is a universal MPC layer that any chain or dApp can plug into for secure cross-chain operations. By supporting common cryptographic standards (ECDSA, Ed25519, Schnorr) and providing the needed light client verifications, Ika could become a kind of “MPC-as-a-service” network for all of Web3, bridging assets and actions in a trust-minimized way.

Business and Investment Perspective

Founding Team and Background

Ika was founded by a team of seasoned cryptography and blockchain specialists, primarily based in Israel. The project’s creator and CEO is Omer Sadika, an entrepreneur with a strong pedigree in the crypto security space. Omer previously co-founded the Odsy Network, another project centered on decentralized wallet infrastructure, and he is the Founder/CEO of dWallet Labs, the company behind Ika. His background includes training at Y Combinator (YC alum) and a focus on cybersecurity and distributed systems. Omer’s experience with Odsy and dWallet Labs directly informed Ika’s vision – in essence, Ika can be seen as an evolution of the “dynamic decentralized wallet” concept Odsy worked on, now implemented as an MPC network on Sui.

Ika’s CTO and co-founder is Yehonatan Cohen Scaly, a cryptography expert who co-authored the 2PC-MPC protocol. Yehonatan leads the R&D for Ika’s novel cryptographic algorithms and had previously worked in cybersecurity (possibly with academic research in cryptography). He has been quoted discussing the limitations of existing threshold schemes and how Ika’s approach overcomes them, reflecting deep expertise in MPC and distributed cryptographic protocols. Another co-founder is David Lachmish, who oversees product development. David’s role is to translate the core technology into developer-friendly products and real-world use cases. The trio of Omer, Yehonatan, and David – along with other researchers like Dr. Dolev Mutzari (VP of Research at dWallet Labs) – anchors Ika’s leadership. Collectively, the team’s credentials include prior startups, academic research contributions, and experience at the intersection of crypto, security, and blockchain. This depth is why Ika is described as being created by “some of the world’s leading cryptography experts”.

In addition to the founders, Ika’s broader team and advisors likely feature individuals with strong cryptography backgrounds. For instance, Dolev Mutzari (mentioned above) is a co-author of the technical paper and instrumental in the protocol design. The presence of such talent gives investors confidence that Ika’s complex technology is in capable hands. Moreover, having a founder (Omer) who already successfully raised funds and built a community around Odsy/dWallet concepts means Ika benefits from lessons learned in previous iterations of the idea. The team’s base in Israel – a country known for its cryptography and cybersecurity sector – also situates them in a rich talent pool for hiring developers and researchers.

Funding Rounds and Key Backers

Ika (and its parent, dWallet Labs) has attracted significant venture funding and strategic investment since its inception. To date it has raised over $21 million across multiple rounds. The project’s initial seed round in August 2022 was $5M, which was remarkable given the bear market conditions at that time. That seed round included a wide array of well-known crypto investors and angels. Notable participants included Node Capital (lead), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures, and others. Prominent individual investors also joined, such as Naval Ravikant (AngelList co-founder and prominent tech investor), Marc Bhargava (co-founder of Tagomi), Rene Reinsberg (co-founder of Celo), and several other industry figures. Such a roster of backers underscored strong confidence in Ika’s approach to decentralized custody even at the idea stage.

In May 2023, Ika raised an additional ~$7.5M in what appears to be a Series A or strategic round, reportedly at a valuation around $250M. This round was led by Blockchange Ventures and Node Capital (again), with participation from Insignius Capital, Rubik Ventures, and others. By this point, the thesis of scalable MPC networks had gained traction, and Ika’s progress likely attracted these investors to double down. The $250M valuation for a relatively early-stage network reflected the market’s expectation that Ika could become foundational infrastructure in web3 (on par with L1 blockchains or major DeFi protocols in terms of value).

The most high-profile investment came in April 2025, when the Sui Foundation announced a strategic investment in Ika. This partnership with Sui’s ecosystem fund pushed Ika’s total funding above $21M and cemented a close alignment with the Sui blockchain. While the exact amount Sui Foundation invested wasn’t publicly disclosed, it’s clear this was a significant endorsement – likely on the order of several million USD. The Sui Foundation’s support is not just financial; it also means Ika gets strong go-to-market assistance within the Sui ecosystem (developer outreach, integration support, marketing, etc.). According to press releases, “Ika…announced a strategic investment from the Sui Foundation, pushing its total funding to over $21 million.” This strategic round, rather than a traditional VC equity round, highlights that Sui sees Ika as critical infrastructure for its blockchain’s future (similar to how Ethereum Foundation might directly back a Layer-2 or interoperability project that benefits Ethereum).

Aside from Sui, other backers worth noting are Node Capital (a China-based crypto fund known for early investments in infrastructure), Lemniscap (a crypto VC focusing on early protocol innovation), and Collider Ventures (Israel-based VC, likely providing local support). Blockchange Ventures leading the 2023 round is notable; Blockchange is a VC that has backed several crypto infrastructure plays and their lead suggests they saw Ika’s tech as potentially category-defining. Additionally, Digital Currency Group (DCG) and Node Capital led a $5M fundraise for dWallet Labs prior to Ika’s rebranding (according to a LinkedIn post by Omer) – DCG’s involvement (via an earlier round for the company) indicates even more support in the background.

In summary, Ika’s funding journey shows a mix of traditional VCs and strategic partners. The Sui Foundation’s involvement particularly stands out, as it not only provides capital but also an integrated ecosystem to deploy Ika’s technology. Investors are essentially betting that Ika will become the go-to solution for decentralized key management and bridging across many networks, and they have valued the project accordingly.

Tokenomics and Economic Model

Ika will have a native utility token called $IKA, which is central to the network’s economics and security model. Uniquely, the IKA token is being launched on the Sui blockchain (as an SUI native asset), even though the Ika network itself is a separate chain. This means IKA will exist as a coin that can be held and transferred on Sui like any other Sui asset, and it will be used in a dual manner: within the Ika network for staking and fees, and on Sui for governance or access in dApps. The tokenomics can be outlined as follows:

  • Gas Fees: Just as ETH is gas in Ethereum or SUI is gas in Sui, IKA serves as the gas/payment for MPC operations on the Ika network. When a user or a dApp requests a signature or dWallet operation, a fee in IKA is paid to the network. These fees compensate validators for the computation and communication work of running the threshold signing protocol. The whitepaper analogizes IKA’s role to Sui’s gas, confirming that all cross-chain transactions facilitated by Ika will incur a small IKA fee. The fee schedule is likely proportional to the complexity of the operation (e.g., a single signature might cost a baseline fee, while more complex multi-step workflows could cost more).

  • Staking and Security: IKA is also a staking token. Validator nodes in the Ika network must be delegated a stake of IKA to participate in consensus and signing. The consensus follows a delegated proof-of-stake similar to Sui’s: token holders delegate IKA to validators, and the weight of each validator in the consensus (and thus in the threshold signature processes) is determined by stake. In each epoch, validators are chosen and their voting power is a function of stake, with the overall set being Byzantine fault tolerant (meaning if a validator set has total stake $X$, up to ~$X/3$ stake could be malicious without breaking the network’s guarantees). Stakers (delegators) are incentivized by staking rewards: Ika’s model likely includes distribution of the collected fees (and possibly inflationary rewards) to validators and their delegators at epoch ends. Indeed, documentation notes that all transaction fees collected are distributed to authorities, who may share a portion with their delegators as rewards. This mirrors the Sui model of rewarding service providers for throughput.

  • Supply and Distribution: As of now (Q2 2025), details on IKA’s total supply, initial distribution, and inflation are not fully public. However, given the funding rounds, we can infer some structure. Likely, a portion of IKA is allocated to early investors (seed and series rounds) and the team, with a large part reserved for community and future incentives. There may be a community sale or airdrop planned, especially since Ika ran a notable NFT campaign raising 1.4M SUI as mentioned in news (this was an NFT art campaign on Sui that set a record; it’s possible participants in that campaign might get IKA rewards or early access). The NFT campaign suggests a strategy to involve the community and bootstrap token distribution to users, not just VCs.

  • Token Launch Timing: The Sui Foundation’s October 2024 announcement indicated “The IKA token will launch natively on Sui, unlocking new functionality and utility in decentralized security”. Mainnet was slated for December 2024, so presumably the token generation event (TGE) would coincide or shortly follow. If mainnet launched on schedule, IKA tokens might have begun distribution in late 2024 or early 2025. The token would then start being used for gas on the Ika network and staking. Before that, on testnet, a temporary token (DWLT on testnet) was used for gas, which had no real value.

  • Use Cases and Value Accrual: The value of IKA as an investment hinges on Ika network usage. As more cross-chain transactions flow through Ika, more fees are paid in IKA, creating demand. Additionally, if many want to run validators or secure the network, they must acquire and stake IKA, which locks up supply (reducing float). Thus IKA has a utility plus governance nature – utility in paying for services and staking, and likely governance in directing the future of the protocol (though governance isn’t explicitly mentioned yet, it’s common for such networks to eventually decentralize control via token voting). One can imagine IKA token holders voting on adding support for new chains, adjusting fee parameters, or other protocol upgrades in the future.

Overall, IKA’s tokenomics aim to balance network security with usability. By launching on Sui, they make it easy for Sui ecosystem users to obtain and use IKA (no separate chain onboarding needed for the token itself), which can jumpstart adoption. Investors will watch metrics like the portion of supply staked (indicating security), the fee revenue (indicating usage), and partnerships that drive transactions (indicating demand for the token).

Business Model and Go-to-Market Strategy

Ika’s business model is that of an infrastructure provider in the blockchain ecosystem. It doesn’t offer a consumer-facing product; instead it offers a protocol service (decentralized key management and transaction execution) that other projects integrate. As such, the primary revenue (or value capture) mechanism is the fee for service – i.e., the gas fees in IKA for using the network. One can liken Ika to a decentralized AWS for key signing: any developer can plug in and use it, paying per use. In the long run, as the network decentralizes, dWallet Labs (the founding company) might capture value by holding a stake in the network and via token appreciation rather than charging SaaS-style fees off-chain.

Go-to-Market (GTM) Strategy: Early on, Ika is targeting blockchain developers and projects that need cross-chain functionality or custody solutions. The alignment with Sui gives a ready pool of such developers. Sui itself, being a newer L1, needs unique features to attract users – and Ika offers cross-chain DeFi, Bitcoin access, and more on Sui, which are compelling features. Thus, Ika’s GTM piggybacks on Sui’s growing ecosystem. Notably, even before mainnet, several Sui projects announced they are integrating Ika:

  • Projects like Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma, and Ekko (all builders on Sui) have “announced their upcoming launches utilizing Ika”, covering use cases from DeFi to gaming. For example, Full Sail might be building an exchange that can trade BTC via Ika; Lucky Kat (a gaming studio) could use Ika to enable in-game assets that reside on multiple chains; Covault likely involves custody solutions, etc. By securing these partnerships early, Ika ensures that upon launch there will be immediate transaction volume and real applications showcasing its capabilities.

  • Ika is also emphasizing institutional use-cases, such as decentralized custody for institutions. In press releases, they highlight “unmatched security for institutional and individual users” in custody via Ika. This suggests Ika could be marketed to crypto custodians, exchanges, or even TradFi players that want a more secure way to manage private keys (perhaps as an alternative or complement to Fireblocks or Copper, which use MPC but in a centralized enterprise setting). In fact, by being a decentralized network, Ika could allow competitors in custody to all rely on the same robust signing network rather than each building their own. This cooperative model could attract institutions that prefer a neutral, decentralized custodian for certain assets.

  • Another angle is AI integrations: Ika mentions “AI Agent guardrails” as a use case. This is forward-looking, playing on the trend of AI autonomy (e.g., AI agents executing on blockchain). Ika can ensure an AI agent (say an autonomous economic agent given control of some funds) cannot run off with the funds because the agent itself isn’t the sole holder of the key – it would still need the user’s share or abide by conditions in Ika. Marketing Ika as providing safety rails for AI in Web3 is a novel angle to capture interest from that sector.

Geographically, the presence of Node Capital and others hints at an Asia focus as well, in addition to the Western market. Sui has a strong Asia community (especially in China). Ika’s NFT campaign on Sui (the art campaign raising 1.4M SUI) indicates a community-building effort – possibly engaging Chinese users who are avid in Sui NFT space. By doing NFT sales or community airdrops, Ika can cultivate a grassroots user base who hold IKA tokens and are incentivized to promote its adoption.

Over time, the business model could extend to offering premium features or enterprise integrations. For instance, while the public Ika network is permissionless, dWallet Labs could spin up private instances or consortium versions for certain clients, or provide consulting services to projects integrating Ika. They could also earn via running some of the validators early on (bootstrap phase) and thus collecting part of the fees.

In summary, Ika’s GTM is strongly tied to ecosystem partnerships. By embedding deeply into Sui’s roadmap (where Sui’s 2025 goals include cross-chain liquidity and unique use cases), Ika ensures it will ride the growth of that L1. Simultaneously, it positions itself as a generalized solution for multi-chain coordination, which can then be pitched to projects on other chains once a success on Sui is demonstrated. The backing from Sui Foundation and the early integration announcements give Ika a significant head start in credibility and adoption compared to if it launched in isolation.

Ecosystem Adoption, Partnerships, and Roadmap

Even at its early stage, Ika has built an impressive roster of ecosystem engagements:

  • Sui Ecosystem Adoption: As mentioned, multiple Sui-based projects are integrating Ika. This means upon Ika’s mainnet launch, we expect to see Sui dApps enabling features like “Powered by Ika” – for example, a Sui lending protocol that lets users deposit BTC, or a DAO on Sui that uses Ika to hold its treasury on multiple chains. The fact that names like Rhei, Atoma, Nativerse (likely DeFi projects) and Lucky Kat (gaming/NFT) are on board shows that Ika’s applicability spans various verticals.

  • Strategic Partnerships: Ika’s most important partnership is with the Sui Foundation itself, which is both an investor and a promoter. Sui’s official channels (blog, etc.) have featured Ika prominently, effectively endorsing it as the interoperability solution for Sui. Additionally, Ika has likely been working with other infrastructure providers. For instance, given the mention of zkLogin (Sui’s Web2 login feature) alongside Ika, there could be a combined use-case where zkLogin handles user authentication and Ika handles cross-chain transactions, together providing a seamless UX. Also, Ika’s mention of Avail (Polygon) in its blogs suggests a partnership or pilot in that ecosystem: perhaps with Polygon Labs or teams building rollups on Avail to use Ika for bridging Bitcoin to those rollups. Another potential partnership domain is with custodians – for example, integrating Ika with wallet providers like Zengo (notable since ZenGo’s co-founder was Omer’s prior project) or with institutional custody tech like Fireblocks. While not confirmed, these would be logical targets (indeed Fireblocks has partnered with Sui elsewhere; one could imagine Fireblocks leveraging Ika for MPC on Sui).

  • Community and Developer Engagement: Ika runs a Discord and likely hackathons to get developers building with dWallets. The technology is novel, so evangelizing it through education is key. The presence of “Use cases” and “Builders” sections on their site, plus blog posts explaining core concepts, indicates a push to get developers comfortable with the concept of dWallets. The more developers understand that they can build cross-chain logic without bridges (and without compromising security), the more organic adoption will grow.

  • Roadmap: As of 2025, Ika’s roadmap included:

    • Alpha and Testnet (2023–2024): The alpha testnet launched in 2024 on Sui, allowing developers to experiment with dWallets and providing feedback. This stage was used to refine the protocol, fix bugs, and run internal audits.
    • Mainnet Launch (Dec 2024): Ika planned to go live on mainnet by end of 2024. If achieved, by now (mid-2025) Ika’s mainnet should be operational. Launch likely included initial support for a set of chains: at least Bitcoin and Ethereum (ECDSA chains) out of the gate, given those were heavily mentioned in marketing.
    • Post-Launch 2025 Goals: In 2025, we expect the focus to be on scaling usage (through Sui apps and possibly expanding to other chains). The team will work on adding Ed25519 and Schnorr support shortly after launch, enabling integration with Solana, Polkadot, and other ecosystems. They will also implement more light clients (perhaps Ethereum light client for Ika, Solana light client, etc.) to broaden the trustless control. Another roadmap item is likely permissionless validator expansion – encouraging more independent validators to join and decentralizing the network further. Since the code is a Sui fork, running an Ika validator is similar to running a Sui node, which many operators can do.
    • Feature Enhancements: Two interesting features hinted in blogs are Encrypted User Shares and Future Transaction signing. Encrypted user share means users can optionally encrypt their private share and store it on-chain (perhaps on Ika or elsewhere) in a way that only they can decrypt, simplifying recovery. Future transaction signing implies the ability to have Ika pre-sign a transaction that executes later when conditions are met. These features increase usability (users won’t have to be online for every action if they pre-approve certain logic, all while maintaining non-custodial security). Delivering these in 2025 would further differentiate Ika’s offering.
    • Ecosystem Growth: By end of 2025, Ika likely aims to have multiple chain ecosystems actively using it. We might see, for example, an Ethereum project using Ika via an oracle (if direct on-chain integration is not yet there) or collaborations with interchain projects like Wormhole or LayerZero, where Ika could serve as the signing mechanism for secure messaging.

The competitive landscape will also shape Ika’s strategy. It’s not alone in offering decentralized key management, so part of its roadmap will involve highlighting its performance edge and unique two-party security in contrast to others. In the next section, we compare Ika to its notable competitors Lit Protocol, Threshold Network, and Zama.

Competitive Analysis: Ika vs. Other MPC/Threshold Networks

Ika operates in a cutting-edge arena of cryptographic networks, where a few projects are pursuing similar goals with varying approaches. Below is a summary comparison of Ika with Lit Protocol, Threshold Network, and Zama (each a representative competitor in decentralized key infrastructure or privacy computing):

AspectIka (Parallel MPC Network)Lit Protocol (PKI & Compute)Threshold Network (tBTC & TSS)Zama (FHE Network)
Launch & StatusFounded 2022; Testnet in 2024; Mainnet launched on Sui in Dec 2024 (early 2025). Token $IKA live on Sui.Launched 2021; Lit nodes network live. Token $LIT (launched 2021). Building “Chronicle” rollup for scaling.Network went live 2022 after Keep/NuCypher merger. Token $T governs DAO. tBTC v2 launched for Bitcoin bridging.In development (no public network yet as of 2025). Raised large VC rounds for R&D. No token yet (FHE tools in alpha stage).
Core Focus/Use-CaseCross-chain interoperability and custody: threshold signing to control native assets across chains (e.g. BTC, ETH) via dWallets. Enables DeFi, multi-chain dApps, etc.Decentralized key management & access control: threshold encryption/decryption and conditional signing via PKPs (Programmable Key Pairs). Popular for gating content, cross-chain automation with JavaScript “Lit Actions”.Threshold cryptography services: e.g. tBTC decentralized Bitcoin-to-Ethereum bridge; threshold ECDSA for digital asset custody; threshold proxy re-encryption (PRE) for data privacy.Privacy-preserving computation: Fully Homomorphic Encryption (FHE) to enable encrypted data processing and private smart contracts. Focus on confidentiality (e.g. private DeFi, on-chain ML) rather than cross-chain control.
ArchitectureFork of Sui blockchain (DAG consensus Mysticeti) modified for MPC. No user smart contracts on Ika; uses off-chain 2PC-MPC protocol among ~N validators + user share. High throughput (10k TPS) design.Decentralized network + L2: Lit nodes run MPC and also a TEE-based JS runtime. “Chronicle” Arbitrum Rollup used to anchor state and coordinate nodes. Uses 2/3 threshold for consensus on key operations.Decentralized network on Ethereum: Node operators are staked with $T and randomly selected into signing groups (e.g. 100 nodes for tBTC). Uses off-chain protocols (GG18, etc.) with on-chain Ethereum contracts for coordination and deposit handling.FHE Toolkits atop existing chains: Zama’s tech (e.g. Concrete, TFHE libraries) enables FHE on Ethereum (fhEVM). Plans for a threshold key management system (TKMS) for FHE keys. Likely will integrate with L1s or run as Layer-2 for private computations.
Security Model2PC-MPC, non-collusive: User’s key share + threshold of N validators (2/3 BFT) required for any signature. No single entity ever has full key. BFT consensus tolerates <33% malicious. Audited by Symbolic (2024).Threshold + TEE: Requires 2/3 of Lit nodes to sign/decrypt. Uses Trusted Execution Environments on each node to run user-provided code (Lit Actions) securely. Security depends on node honesty and hardware security.Threshold multi-party: e.g. for tBTC, a randomly selected group of ~100 nodes must reach a threshold (e.g. 51) to sign BTC transactions. Economic incentives ($T staking, slashing) to keep honest majority. DAO governed; security incidents would be handled via governance.FHE-based: Security relies on cryptographic hardness of FHE (learning with errors, etc.) – data remains encrypted at all times. Zama’s TKMS indicates use of threshold cryptography to manage FHE keys as well. Not a live network yet; security under review by academics.
PerformanceSub-second latency, ~10,000 signatures/sec in theory. Scales to hundreds or thousands of nodes without major perf loss (broadcast & batching approach). Suitable for real-time dApp use (trading, gaming).Moderate latency (heavier due to TEE and consensus overhead). Lit has ~50 nodes; uses “shadow splicing” to scale but large node count can degrade performance. Good for moderate-frequency tasks (opening access, occasional tx signing). Chronicle L2 helps batching.Lower throughput, higher latency: tBTC minting can take minutes (waiting for Bitcoin confirmations + threshold signing) and uses small groups to sign. Threshold’s focus is quality (security) over quantity – fine for bridging transactions and access control, not designed for thousands TPS.Heavy computation latency: FHE is currently much slower than plaintext computation (orders of magnitude). Zama is optimizing, but running private contracts will be slower and costlier than normal ones. Not aimed at high-frequency tasks; targeted at complex computations where privacy is paramount.
DecentralizationHigh – permissionless validator set, hundreds of validators possible. Delegated PoS (Sui-style) ensures open participation and decentralized governance over time. User always in the loop (can’t be bypassed).Medium – currently ~30-50 core nodes run by Lit team and partners. Plans to decentralize further. Nodes do heavy tasks (MPC + TEE), so scaling out is non-trivial. Governance not fully decentralized yet (Lit DAO exists but early).High – large pool of stakers; however actual signing done by selected groups (not entire network at once). The network is as decentralized as its stake distribution. Governed by Threshold DAO (token holder votes) – mature decentralization in governance.N/A (for network) – Zama is more a company-driven project now. If fhEVM or networks launch, initially likely centralized or limited set of nodes (given complexity). Over time could decentralize execution of FHE transactions, but that’s uncharted territory in 2025.
Token and Incentives$IKA (Sui-based) for gas fees, staking, and potentially governance. Incentive: earn fees for running validators; token appreciates with network usage. Sui Foundation backing gives it ecosystem value.$LIT token – used for governance and maybe fees for advanced services. Lit Actions currently free to developers (no gas); long-term may introduce fee model. $LIT incentivizes node operation (stakers) but exact token economics evolving.$T token – staked by nodes, governs the DAO treasury and protocol upgrades. Nodes earn in $T and fees (in ETH or tBTC fees). $T secures network (slashing for misbehavior). Also used in liquidity programs for tBTC adoption.No token (yet) – Zama is VC-funded; might introduce a token if they launch a network service (could be used for paying for private computation or staking to secure networks running FHE contracts). Currently developers use Zama’s tools without a token.
Key BackersSui Foundation (strategic investor); VCs: Node Capital, Blockchange, Lemniscap, Collider; angels like Naval Ravikant. Strong support from Sui ecosystem.Backed by 1kx, Pantera, Coinbase Ventures, Framework, etc. (Raised $13M in 2022). Has growing developer community via Lit DAO. Partnerships with Ceramic, NFT projects for access control.Emerged from Keep & NuCypher communities (backed by a16z, Polychain in past). Threshold is run by DAO; no new VC funding post-merger (grants from Ethereum Community Fund, etc.). Partnerships: works with Curve, Aave (tBTC integrations).Backed by a16z, SoftBank, Multicoin Capital (raised $73M Series A). Close ties with Ethereum Foundation research (Rand Hindi, CEO, is an outspoken FHE advocate in Ethereum). Collaborating with projects like Optalysys for hardware acceleration.

Ika’s Competitive Edge: Ika’s differentiators lie in its performance at scale and unique security model. Compared to Lit Protocol, Ika can support far more signers and much higher throughput, making it suitable for use cases (like high-volume trading or gaming) that Lit’s network would struggle with. Ika also does not rely on Trusted Execution Environments, which some developers are wary of (due to potential exploits in SGX); instead, Ika achieves trustlessness purely with cryptography and consensus. Against Threshold Network, Ika offers a more general-purpose platform. Threshold is largely focused on Bitcoin↔Ethereum bridging (tBTC) and a couple of cryptographic services like proxy re-encryption, whereas Ika is a flexible interoperability layer that can work with any chain and asset out-of-the-box. Also, Ika’s user-in-the-loop model means it doesn’t require over-collateralization or insurance for deposits (tBTC v2 uses a robust but complex economic model to secure BTC deposits, whereas in Ika the user never gives up control in the first place). Compared to Zama, Ika addresses a different problem – Zama targets privacy, while Ika targets interoperability. However, it’s conceivable that in the future the two could complement each other (e.g., using FHE on Ika-stored assets). For now, Ika has the advantage of being operational sooner in a niche with immediate demand (bridges and MPC networks are needed today, whereas FHE is still maturing).

One potential challenge for Ika is market education and trust. It’s introducing a novel way of doing cross-chain interactions (dWallets instead of traditional lock-and-mint bridges). It will need to demonstrate its security in practice over time to win the same level of trust that, say, the Threshold Network has gradually earned (Threshold had to prove out tBTC after an earlier version was paused due to risks). If Ika’s technology works as advertised, it effectively leapfrogs the competition by solving the trilemma of decentralization, security, and speed in the MPC space. The strong backing from Sui and the extensive audits/papers lend credibility.

In conclusion, Ika stands out among MPC networks for its ambitious scalability and user-centric security model. Investors see it as a bet on the future of cross-chain coordination – one where users can seamlessly move value and logic across many blockchains without ever giving up control of their keys. If Ika achieves broad adoption, it could become as integral to Web3 infrastructure as cross-chain messaging protocols or major Layer-1 blockchains themselves. The coming year (2025) will be critical as Ika’s mainnet and first use cases go live, proving whether this cutting-edge cryptography can deliver on its promises in real market conditions. The early signs – strong technical fundamentals, an active pipeline of integrations, and substantial investor support – suggest that Ika has a real shot at redefining blockchain interoperability with MPC.

Sources: Primary information was gathered from Ika’s official documentation and whitepaper, Sui Foundation announcements, press releases and funding news, as well as competitor technical docs and analyses for context (Lit Protocol’s Messari report, Threshold Network documentation, and Zama’s FHE descriptions). All information is up-to-date as of 2025.

Programmable Privacy in Blockchain: Off‑Chain Compute with On‑Chain Verification

· 47 min read
Dora Noda
Software Engineer

Public blockchains provide transparency and integrity at the cost of privacy – every transaction and contract state is exposed to all participants. This openness creates problems like MEV (Miner Extractable Value) attacks, copy-trading, and leakage of sensitive business logic. Programmable privacy aims to solve these issues by allowing computations on private data without revealing the data itself. Two emerging cryptographic paradigms are making this possible: Fully Homomorphic Encryption Virtual Machines (FHE-VM) and Zero-Knowledge (ZK) Coprocessors. These approaches enable off-chain or encrypted computation with on-chain verification, preserving confidentiality while retaining trustless correctness. In this report, we dive deep into FHE-VM and ZK-coprocessor architectures, compare their trade-offs, and explore use cases across finance, identity, healthcare, data markets, and decentralized machine learning.

Fully Homomorphic Encryption Virtual Machine (FHE-VM)

Fully Homomorphic Encryption (FHE) allows arbitrary computations on encrypted data without ever decrypting it. An FHE Virtual Machine integrates this capability into blockchain smart contracts, enabling encrypted contract state and logic. In an FHE-enabled blockchain (often called an fhEVM for EVM-compatible designs), all inputs, contract storage, and outputs remain encrypted throughout execution. This means validators can process transactions and update state without learning any sensitive values, achieving on-chain execution with data confidentiality.

Architecture and Design of FHE-VM

A typical FHE-VM extends a standard smart contract runtime (like the Ethereum Virtual Machine) with native support for encrypted data types and operations. For example, Zama’s FHEVM introduces encrypted integers (euint8, euint32, etc.), encrypted booleans (ebool), and even encrypted arrays as first-class types. Smart contract languages like Solidity are augmented via libraries or new opcodes so developers can perform arithmetic (add, mul, etc.), logical operations, and comparisons directly on ciphertexts. Under the hood, these operations invoke FHE primitives (e.g. using the TFHE library) to manipulate encrypted bits and produce encrypted results.

Encrypted state storage is supported so that contract variables remain encrypted in the blockchain state. The execution flow is typically:

  1. Client-Side Encryption: Users encrypt their inputs locally using the public FHE key before sending transactions. The encryption key is public (for encryption and evaluation), while the decryption key remains secret. In some designs, each user manages their own key; in others, a single global FHE key is used (discussed below).
  2. On-Chain Homomorphic Computation: Miners/validators execute the contract with encrypted opcodes. They perform the same deterministic homomorphic operations on the ciphertexts, so consensus can be reached on the encrypted new state. Crucially, validators never see plaintext data – they just see “gibberish” ciphertext but can still process it consistently.
  3. Decryption (Optional): If a result needs to be revealed or used off-chain, an authorized party with the private key can decrypt the output ciphertext. Otherwise, results remain encrypted and can be used as inputs to further transactions (allowing consecutive computations on persistent encrypted state).

A major design consideration is key management. One approach is per-user keys, where each user holds their secret key and only they can decrypt outputs relevant to them. This maximizes privacy (no one else can ever decrypt your data), but homomorphic operations cannot mix data encrypted under different keys without complex multi-key protocols. Another approach, used by Zama’s FHEVM, is a global FHE key: a single public key encrypts all contract data and a distributed set of validators holds shares of the threshold decryption key. The public encryption and evaluation keys are published on-chain, so anyone can encrypt data to the network; the private key is split among validators who can collectively decrypt if needed under a threshold scheme. To prevent validator collusion from compromising privacy, Zama employs a threshold FHE protocol (based on their Noah’s Ark research) with “noise flooding” to make partial decryptions secure. Only if a sufficient quorum of validators cooperates can a plaintext be recovered, for example to serve a read request. In normal operation, however, no single node ever sees plaintext – data remains encrypted on-chain at all times.

Access control is another crucial component. FHE-VM implementations include fine-grained controls to manage who (if anyone) can trigger decryptions or access certain encrypted fields. For instance, Cypher’s fhEVM supports Access Control Lists on ciphertexts, allowing developers to specify which addresses or contracts can interact with or re-encrypt certain data. Some frameworks support re-encryption: the ability to transfer an encrypted value from one user’s key to another’s without exposing plaintext. This is useful for things like data marketplaces, where a data owner can encrypt a dataset with their key, and upon purchase, re-encrypt it to the buyer’s key – all on-chain, without ever decrypting publicly.

Ensuring Correctness and Privacy

One might ask: if all data is encrypted, how do we enforce correctness of contract logic? How can the chain prevent invalid operations if it can’t “see” the values? FHE by itself doesn’t provide a proof of correctness – validators can perform the homomorphic steps, but they can’t inherently tell if a user’s encrypted input was valid or if a conditional branch should be taken, etc., without decrypting. Zero-knowledge proofs (ZKPs) can complement FHE to solve this gap. In an FHE-VM, typically users must provide a ZK proof attesting to certain plaintext conditions whenever needed. Zama’s design, for example, uses a ZK Proof of Plaintext Knowledge (ZKPoK) to accompany each encrypted input. This proves that the user knows the plaintext corresponding to their ciphertext and that it meets expected criteria, without revealing the plaintext itself. Such “certified ciphertexts” prevent a malicious user from submitting a malformed encryption or an out-of-range value. Similarly, for operations that require a decision (e.g. ensure account balance ≥ withdrawal amount), the user can supply a ZK proof that this condition holds true on the plaintexts before the encrypted operation is executed. In this way, the chain doesn’t decrypt or see the values, but it gains confidence that the encrypted transactions follow the rules.

Another approach in FHE rollups is to perform off-chain validation with ZKPs. Fhenix (an L2 rollup using FHE) opts for an optimistic model where a separate network component called a Threshold Service Network can decrypt or verify encrypted results, and any incorrect computation can be challenged with a fraud-proof. In general, combining FHE + ZK or fraud proofs ensures that encrypted execution remains trustless. Validators either collectively decrypt only when authorized, or they verify proofs that each encrypted state transition was valid without needing to see plaintext.

Performance considerations: FHE operations are computationally heavy – many orders of magnitude slower than normal arithmetic. For example, a simple 64-bit addition on Ethereum costs ~3 gas, whereas an addition on an encrypted 64-bit integer (euint64) under Zama’s FHEVM costs roughly 188,000 gas. Even an 8-bit add can cost ~94k gas. This enormous overhead means a straightforward implementation on existing nodes would be impractically slow and costly. FHE-VM projects tackle this with optimized cryptographic libraries (like Zama’s TFHE-rs library for binary gate bootstrapping) and custom EVM modifications for performance. For instance, Cypher’s modified Geth client adds new opcodes and optimizes homomorphic instruction execution in C++/assembly to minimize overhead. Nevertheless, achieving usable throughput requires acceleration. Ongoing work includes using GPUs, FPGAs, and even specialized photonic chips to speed up FHE computations. Zama reports their FHE performance improved 100× since 2024 and is targeting thousands of TPS with GPU/FPGA acceleration. Dedicated FHE co-processor servers (such as Optalysys’s LightLocker Node) can plug into validator nodes to offload encrypted operations to hardware, supporting >100 encrypted ERC-20 transfers per second per node. As hardware and algorithms improve, the gap between FHE and plain computation will narrow, enabling private contracts to approach more practical speeds.

Compatibility: A key goal of FHE-VM designs is to remain compatible with existing development workflows. Cypher’s and Zama’s fhEVM implementations allow developers to write contracts in Solidity with minimal changes – using a library to declare encrypted types and operations. The rest of the Ethereum toolchain (Remix, Hardhat, etc.) can still be used, as the underlying modifications are mostly at the client/node level. This lowers the barrier to entry: developers don’t need to be cryptography experts to write a confidential smart contract. For example, a simple addition of two numbers can be written as euint32 c = a + b; and the FHEVM will handle the encryption-specific details behind the scenes. The contracts can even interoperate with normal contracts – e.g. an encrypted contract could output a decrypted result to a standard contract if desired, allowing a mix of private and public parts in one ecosystem.

Current FHE-VM Projects: Several projects are pioneering this space. Zama (a Paris-based FHE startup) developed the core FHEVM concept and libraries (TFHE-rs and an fhevm-solidity library). They do not intend to launch their own chain, but rather provide infrastructure to others. Inco is an L1 blockchain (built on Cosmos SDK with Evmos) that integrated Zama’s FHEVM to create a modular confidential chain. Their testnets (named Gentry and Paillier) showcase encrypted ERC-20 transfers and other private DeFi primitives. Fhenix is an Ethereum Layer-2 optimistic rollup using FHE for privacy. It decided on an optimistic (fraud-proof) approach rather than ZK-rollup due to the heavy cost of doing FHE and ZK together for every block. Fhenix uses the same TFHE-rs library (with some modifications) and introduces a Threshold Service Network for handling decryptions in a decentralized way. There are also independent teams like Fhenix (now rebranded) and startups exploring MPC + FHE hybrids. Additionally, Cypher (by Z1 Labs) is building a Layer-3 network focused on AI and privacy, using an fhEVM with features like secret stores and federated learning support. The ecosystem is nascent but growing rapidly, fueled by significant funding – e.g. Zama became a “unicorn” with >$130M raised by 2025 to advance FHE tech.

In summary, an FHE-VM enables privacy-preserving smart contracts by executing all logic on encrypted data on-chain. This paradigm ensures maximum confidentiality – nothing sensitive is ever exposed in transactions or state – while leveraging the existing blockchain consensus for integrity. The cost is increased computational burden on validators and complexity in key management and proof integration. Next, we explore an alternative paradigm that offloads compute entirely off-chain and only uses the chain for verification: the zero-knowledge coprocessor.

Zero-Knowledge Coprocessors (ZK-Coprocessors)

A ZK-coprocessor is a new blockchain architecture pattern where expensive computations are performed off-chain, and a succinct zero-knowledge proof of their correctness is verified on-chain. This allows smart contracts to harness far greater computational power and data than on-chain execution would allow, without sacrificing trustlessness. The term coprocessor is used by analogy to hardware coprocessors (like a math co-processor or GPU) that handle specialized tasks for a CPU. Here, the blockchain’s “CPU” (the native VM like EVM) delegates certain tasks to a zero-knowledge proof system which acts as a cryptographic coprocessor. The ZK-coprocessor returns a result and a proof that the result was computed correctly, which the on-chain contract can verify and then use.

Architecture and Workflow

In a typical setup, a dApp developer identifies parts of their application logic that are too expensive or complex for on-chain execution (e.g. large computations over historical data, heavy algorithms, ML model inference, etc.). They implement those parts as an off-chain program (in a high-level language or circuit DSL) that can produce a zero-knowledge proof of its execution. The on-chain component is a verifier smart contract that checks proofs and makes the results available to the rest of the system. The flow can be summarized as:

  1. Request – The on-chain contract triggers a request for a certain computation to be done off-chain. This could be initiated by a user transaction or by one contract calling into the ZK-coprocessor’s interface. For example, a DeFi contract might call “proveInterestRate(currentState)” or a user calls “queryHistoricalData(query)”.
  2. Off-Chain Execution & Proving – An off-chain service (which could be a decentralized network of provers or a trusted service, depending on the design) picks up the request. It gathers any required data (on-chain state, off-chain inputs, etc.) and executes the computation in a special ZK Virtual Machine (ZKVM) or circuit. During execution, a proof trace is generated. At the end, the service produces a succinct proof (e.g. a SNARK or STARK) attesting that “Computing function F on input X yields output Y” and optionally attesting to data integrity (more on this below).
  3. On-Chain Verification – The proof and result are returned to the blockchain (often via a callback function). The verifier contract checks the proof’s validity using efficient cryptographic verification (pairing checks, etc.). If valid, the contract can now trust the output Y as correct. The result can be stored in state, emitted as an event, or fed into further contract logic. If the proof is invalid or not provided within some time, the request can be considered failed (and potentially some fallback or timeout logic triggers).

Figure 1: Architecture of a ZK Coprocessor (RISC Zero Bonsai example). Off-chain, a program runs on a ZKVM with inputs from the smart contract call. A proof of execution is returned on-chain via a relay contract, which invokes a callback with the verified results.

Critically, the on-chain gas cost for verification is constant (or grows very slowly) regardless of how complex the off-chain computation was. Verifying a succinct proof might cost on the order of a few hundred thousand gas (a fraction of an Ethereum block), but that proof could represent millions of computational steps done off-chain. As one developer quipped, “Want to prove one digital signature? ~$15. Want to prove one million signatures? Also ~$15.”. This scalability is a huge win: dApps can offer complex functionalities (big data analytics, elaborate financial models, etc.) without clogging the blockchain.

The main components of a ZK-coprocessor system are:

  • Proof Generation Environment: This can be a general-purpose ZKVM (able to run arbitrary programs) or custom circuits tailored to specific computations. Approaches vary:

    • Some projects use handcrafted circuits for each supported query or function (maximizing efficiency for that function).
    • Others provide a Domain-Specific Language (DSL) or an Embedded DSL that developers use to write their off-chain logic, which is then compiled into circuits (balancing ease-of-use and performance).
    • The most flexible approach is a zkVM: a virtual machine (often based on RISC architectures) where programs can be written in standard languages (Rust, C, etc.) and automatically proven. This sacrifices performance (simulating a CPU in a circuit adds overhead) for maximum developer experience.
  • Data Access and Integrity: A unique challenge is feeding the off-chain computation with the correct data, especially if that data resides on the blockchain (past blocks, contract states, etc.). A naive solution is to have the prover read from an archive node and trust it – but that introduces trust assumptions. ZK-coprocessors instead typically prove that any on-chain data used was indeed authentic by linking to Merkle proofs or state commitments. For example, the query program might take a block number and a Merkle proof of a storage slot or transaction, and the circuit will verify that proof against a known block header hash. Three patterns exist:

    1. Inline Data: Put the needed data on-chain (as input to the verifier) so it can be directly checked. This is very costly for large data and undermines the whole point.
    2. Trust an Oracle: Have an oracle service feed the data to the proof and vouch for it. This is simpler but reintroduces trust in a third party.
    3. Prove Data Inclusion via ZK: Incorporate proofs of data inclusion in the chain’s history within the zero-knowledge circuit itself. This leverages the fact that each Ethereum block header commits to the entire prior state (via state root) and transaction history. By verifying Merkle Patricia proofs of the data within the circuit, the output proof assures the contract that “this computation used genuine blockchain data from block N” with no additional trust needed.

    The third approach is the most trustless and is used by advanced ZK-coprocessors like Axiom and Xpansion (it does increase proving cost, but is preferable for security). For instance, Axiom’s system models Ethereum’s block structure, state trie, and transaction trie inside its circuits, so it can prove statements like “the account X had balance Y at block N or “a transaction with certain properties occurred in block N”. It leverages the fact that given a recent trusted block hash, one can recursively prove inclusion of historical data without trusting any external party.

  • Verifier Contract: This on-chain contract contains the verifying key and logic to accept or reject proofs. For SNARKs like Groth16 or PLONK, the verifier might do a few elliptic curve pairings; for STARKs, it might do some hash computations. Performance optimizations like aggregation and recursion can minimize on-chain load. For example, RISC Zero’s Bonsai uses a STARK-to-SNARK wrapper: it runs a STARK-based VM off-chain for speed, but then generates a small SNARK proof attesting to the STARK’s validity. This shrinks proof size from hundreds of kilobytes to a few hundred bytes, making on-chain verification feasible and cheap. The Solidity verifier then just checks the SNARK (which is a constant-time operation).

In terms of deployment, ZK-coprocessors can function as layer-2 like networks or as pure off-chain services. Some, like Axiom, started as a specialized service for Ethereum (with Paradigm’s backing) where developers submit queries to Axiom’s prover network and get proofs on-chain. Axiom’s tagline was providing Ethereum contracts “trustless access to all on-chain data and arbitrary expressive compute over it.” It effectively acts as a query oracle where the answers are verified by ZKPs instead of trust. Others, like RISC Zero’s Bonsai, offer a more open platform: any developer can upload a program (compiled to a RISC-V compatible ZKVM) and use Bonsai’s proving service via a relay contract. The relay pattern, as illustrated in Figure 1, involves a contract that mediates requests and responses: the dApp contract calls the relay to ask for a proof, the off-chain service listens for this (e.g. via event or direct call), computes the proof, and then the relay invokes a callback function on the dApp contract with the result and proof. This asynchronous model is necessary because proving may take from seconds to minutes depending on complexity. It introduces a latency (and a liveness assumption that the prover will respond), whereas FHE-VM computations happen synchronously within a block. Designing the application to handle this async workflow (possibly akin to Oracle responses) is part of using a ZK-coprocessor.

Notable ZK-Coprocessor Projects

  • Axiom: Axiom is a ZK coprocessor tailored for Ethereum, focused originally on proving historical on-chain data queries. It uses the Halo2 proving framework (a Plonk-ish SNARK) to create proofs that incorporate Ethereum’s cryptographic structures. In Axiom’s system, a developer can query things like “what was the state of contract X at block N?” or perform a computation over all transactions in a range. Under the hood, Axiom’s circuits had to implement Ethereum’s state/trie logic, even performing elliptic curve operations and SNARK verification inside the circuit to support recursion. Trail of Bits, in an audit, noted the complexity of Axiom’s Halo2 circuits modeling entire blocks and states. After auditing, Axiom generalized their tech into an OpenVM, allowing arbitrary Rust code to be proved with the same Halo2-based infrastructure. (This mirrors the trend of moving from domain-specific circuits to a more general ZKVM approach.) The Axiom team demonstrated ZK queries that Ethereum natively cannot do, enabling stateless access to any historical data with cryptographic integrity. They have also emphasized security, catching and fixing under-constrained circuit bugs and ensuring soundness. While Axiom’s initial product was shut down during their pivot, their approach remains a landmark in ZK coprocessors.

  • RISC Zero Bonsai: RISC Zero is a ZKVM based on the RISC-V architecture. Their zkVM can execute arbitrary programs (written in Rust, C++ and other languages compiled to RISC-V) and produce a STARK proof of execution. Bonsai is RISC Zero’s cloud service that provides this proving on demand, acting as a coprocessor for smart contracts. To use it, a developer writes a program (say a function that performs complex math or verifies an off-chain API response), uploads it to the Bonsai service, and deploys a corresponding verifier contract. When the contract needs that computation, it calls the Bonsai relay which triggers the proof generation and returns the result via callback. One example application demonstrated was off-chain governance computation: RISC Zero showed a DAO using Bonsai to tally votes and compute complex voting metrics off-chain, then post a proof so that the on-chain Governor contract could trust the outcome with minimal gas cost. RISC Zero’s technology emphasizes that developers can use familiar programming paradigms – for instance, writing a Rust function to compute something – and the heavy lifting of circuit creation is handled by the zkVM. However, proofs can be large, so as noted earlier they implemented a SNARK compression for on-chain verification. In August 2023 they successfully verified RISC Zero proofs on Ethereum’s Sepolia testnet, costing on the order of 300k gas per proof. This opens the door for Ethereum dApps to use Bonsai today as a scaling and privacy solution. (Bonsai is still in alpha, not production-ready, and uses a temporary SNARK setup without a ceremony.)

  • Others: There are numerous other players and research initiatives. Expansion/Xpansion (as mentioned in a blog) uses an embedded DSL approach, where developers can write queries over on-chain data with a specialized language, and it handles proof generation internally. StarkWare’s Cairo and Polygon’s zkEVM are more general ZK-rollup VMs, but their tech could be repurposed for coprocessor-like use by verifying proofs within L1 contracts. We also see projects in the ZKML (ZK Machine Learning) domain, which effectively act as coprocessors to verify ML model inference or training results on-chain. For example, a zkML setup can prove that “a neural network inference on private inputs produced classification X” without revealing the inputs or doing the computation on-chain. These are special cases of the coprocessor concept applied to AI.

Trust assumptions: ZK-coprocessors rely on the soundness of the cryptographic proofs. If the proof system is secure (and any trusted setup is done honestly), then an accepted proof guarantees the computation was correct. No additional trust in the prover is needed – even a malicious prover cannot convince the verifier of a false statement. However, there is a liveness assumption: someone must actually perform the off-chain computation and produce the proof. In practice this might be a decentralized network (with incentives or fees to do the work) or a single service operator. If no one provides the proof, the on-chain request might remain unresolved. Another subtle trust aspect is data availability for off-chain inputs that aren’t on the blockchain. If the computation depends on some private or external data, the verifier can’t know if that data was honestly provided unless additional measures (like data commitments or oracle signatures) are used. But for purely on-chain data computations, the mechanisms described ensure trustlessness equivalent to the chain itself (Axiom argued their proofs offer “security cryptographically equivalent to Ethereum” for historical queries).

Privacy: Zero-knowledge proofs also inherently support privacy – the prover can keep inputs hidden while proving statements about them. In a coprocessor context, this means a proof can allow a contract to use a result that was derived from private data. For example, a proof might show “user’s credit score > 700, so approve loan” without revealing the actual credit score or raw data. Axiom’s use-case was more about publicly known data (blockchain history), so privacy wasn’t the focus there. But RISC Zero’s zkVM could be used to prove assertions about secret data provided by a user: the data stays off-chain and only the needed outcome goes on-chain. It’s worth noting that unlike FHE, a ZK proof doesn’t usually provide ongoing confidentiality of state – it’s a one-time proof. If a workflow needs maintaining a secret state across transactions, one might build it by having the contract store a commitment to the state and each proof showing a valid state transition from old commitment to new, with secrets hidden. This is essentially how zk-rollups for private transactions (like Aztec or Zcash) work. So ZK coprocessors can facilitate fully private state machines, but the implementation is nontrivial; often they are used for one-off computations where either the input or the output (or both) can be private as needed.

Developer experience: Using a ZK-coprocessor typically requires learning new tools. Writing custom circuits (option (1) above) is quite complex and usually only done for narrow purposes. Higher-level options like DSLs or zkVMs make life easier but still add overhead: the dev must write and deploy off-chain code and manage the interaction. In contrast to FHE-VM where the encryption is mostly handled behind the scenes and the developer writes normal smart contract code, here the developer needs to partition their logic and possibly write in a different language (Rust, etc.) for the off-chain part. However, initiatives like Noir, Leo, Circom DSLs or RISC Zero’s approach are rapidly improving accessibility. For instance, RISC Zero provides templates and Foundry integration such that a developer can simulate their off-chain code locally (for correctness) and then seamlessly hook it into solidity tests via the Bonsai callback. Over time, we can expect development frameworks that abstract away whether a piece of logic is executed via ZK proof or on-chain – the compiler or tooling might decide based on cost.

FHE-VM vs ZK-Coprocessor: Comparison

Both FHE-VMs and ZK-coprocessors enable a form of “compute on private data with on-chain assurance”, but they differ fundamentally in architecture. The table below summarizes key differences:

AspectFHE-VM (Encrypted On-Chain Execution)ZK-Coprocessor (Off-Chain Proving)
Where computation happensDirectly on-chain (all nodes execute homomorphic operations on ciphertexts).Off-chain (a prover or network executes the program; only a proof is verified on-chain).
Data confidentialityFull encryption: data remains encrypted at all times on-chain; validators never see plaintext. Only holders of decryption keys can decrypt outputs.Zero-knowledge: prover’s private inputs never revealed on-chain; proof reveals no secrets beyond what’s in public outputs. However, any data used in computation that must affect on-chain state must be encoded in the output or commitment. Secrets remain off-chain by default.
Trust modelTrust in consensus execution and cryptography: if majority of validators follow protocol, encrypted execution is deterministic and correct. No external trust needed for computation correctness (all nodes recompute it). Must trust FHE scheme security (typically based on lattice hardness) for privacy. In some designs, also trust that no collusion of enough validators can occur to misuse threshold keys.Trust in the proof system security (soundness of SNARK/STARK). If proof verifies, result is correct with cryptographic certainty. Off-chain provers cannot cheat the math. There is a liveness assumption on provers to actually do the work. If using a trusted setup (e.g. SNARK SRS), must trust that it was generated honestly or use transparent/no-setup systems.
On-chain cost and scalabilityHigh per-transaction cost: Homomorphic ops are extremely expensive computationally, and every node must perform them. Gas costs are high (e.g. 100k+ gas for a single 8-bit addition). Complex contracts are limited by what every validator can compute in a block. Throughput is much lower than normal smart contracts unless specialized hardware is employed. Scalability is improved by faster cryptography and hardware acceleration, but fundamentally each operation grows chain workload.Low verification cost: Verifying a succinct proof is efficient and constant-size, so on-chain gas is modest (hundreds of thousands gas for any size computation). This decouples complexity from on-chain resource limits – large computations have no extra on-chain cost. Thus, it scales in terms of on-chain load. Off-chain, proving time can be significant (minutes or more for huge tasks) and might require powerful machines, but this doesn’t directly slow the blockchain. Overall throughput can be high as long as proofs can be generated in time (potential parallel prover networks).
LatencyResults are available immediately in the same transaction/block, since computation occurs during execution. No additional round-trips – synchronous operation. However, longer block processing time might increase blockchain latency if FHE ops are slow.Inherently asynchronous. Typically requires one transaction to request and a later transaction (or callback) to provide the proof/result. This introduces delay (possibly seconds to hours depending on proof complexity and proving hardware). Not suitable for instant finality of a single transaction – more like an async job model.
Privacy guaranteesStrong: Everything (inputs, outputs, intermediate state) can remain encrypted on-chain. You can have long-lived encrypted state that multiple transactions update without ever revealing it. Only authorized decryption actions (if any) reveal outputs, and those can be controlled via keys/ACLs. However, side-channel considerations like gas usage or event logs must be managed so they don’t leak patterns (fhEVM designs strive for data-oblivious execution with constant gas for operations to avoid leaks).Selective: The proof reveals whatever is in the public outputs or is necessary to verify (e.g. a commitment to initial state). Designers can ensure that only the intended result is revealed, and all other inputs remain zero-knowledge hidden. But unlike FHE, the blockchain typically doesn’t store the hidden state – privacy is achieved by keeping data off-chain entirely. If a persistent private state is needed, the contract may store a cryptographic commitment to it (so state updates still reveal a new commitment each time). Privacy is limited by what you choose to prove; you have flexibility to prove e.g. a threshold was met without revealing exact values.
Integrity enforcementBy design, all validators recompute the next state homomorphically, so if a malicious actor provides a wrong ciphertext result, others will detect a mismatch – consensus fails unless everyone gets the same result. Thus, integrity is enforced by redundant execution (like normal blockchain, just on encrypted data). Additional ZK proofs are often used to enforce business rules (e.g. user couldn’t violate a constraint) because validators can’t directly check plaintext conditions.Integrity is enforced by the verifier contract checking the ZK proof. As long as the proof verifies, the result is guaranteed to be consistent with some valid execution of the off-chain program. No honest-majority assumption needed for correctness – even a single honest verifier (the contract code itself) suffices. The on-chain contract will simply reject any false proof or missing proof (similar to how it would reject an invalid signature). One consideration: if the prover aborts or delays, the contract may need fallback logic (or users may need to try again later), but it won’t accept incorrect results.
Developer experiencePros: Can largely use familiar smart contract languages (Solidity, etc.) with extensions. The confidentiality is handled by the platform – devs worry mainly about what to encrypt and who holds keys. Composition of encrypted and normal contracts is possible, maintaining the composability of DeFi (just with encrypted variables). Cons: Must understand FHE limitations – e.g. no direct conditional jumps on secret data without special handling, limited circuit depth (though bootstrapping in TFHE allows arbitrary length of computation at expense of time). Debugging encrypted logic can be tricky since you can’t easily introspect runtime values without the key. Also, key management and permissioning add complexity to contract design.Pros: Potentially use any programming language for off-chain part (especially with a zkVM). Leverage existing code/libraries in off-chain program (with caveats for ZK-compatibility). No custom cryptography needed by developer if using a general ZKVM – they write normal code and get a proof. Also, the heavy computation can use libraries (e.g. machine learning code) that would never run on-chain. Cons: Developers must orchestrate off-chain infrastructure or use a proving service. Handling asynchronous workflows and integrating them with on-chain logic requires more design work (e.g. storing a pending state, waiting for callback). Writing efficient circuits or zkVM code might require learning new constraints (e.g. no floating point, use fixed-point or special primitives; avoid heavy branching that blows up proving time; optimize for constraints count). There is also the burden of dealing with proof failures, timeouts, etc., which are not concerns in regular solidity. The ecosystem of tools is growing, but it’s a new paradigm for many.

Both approaches are actively being improved, and we even see convergence: as noted, ZKPs are used inside FHE-VMs for certain checks, and conversely some researchers propose using FHE to keep prover inputs private in ZK (so a cloud prover doesn’t see your secret data). It’s conceivable future systems will combine them – e.g. performing FHE off-chain and then proving the correctness of that to chain, or using FHE on-chain but ZK-proving to light clients that the encrypted ops were done right. Each technique has strengths: FHE-VM offers continuous privacy and real-time interaction at the cost of heavy computation, whereas ZK-coprocessors offer scalability and flexibility at the cost of latency and complexity.

Use Cases and Implications

The advent of programmable privacy unlocks a wealth of new blockchain applications across industries. Below we explore how FHE-VMs and ZK-coprocessors (or hybrids) can empower various domains by enabling privacy-preserving smart contracts and a secure data economy.

Confidential DeFi and Finance

In decentralized finance, privacy can mitigate front-running, protect trading strategies, and satisfy compliance without sacrificing transparency where needed. Confidential DeFi could allow users to interact with protocols without revealing their positions to the world.

  • Private Transactions and Hidden Balances: Using FHE, one can implement confidential token transfers (encrypted ERC-20 balances and transactions) or shielded pools on a blockchain L1. No observer can see how much of a token you hold or transferred, eliminating the risk of targeted attacks based on holdings. ZK proofs can ensure balances stay in sync and no double-spending occurs (similar to Zcash but on smart contract platforms). An example is a confidential AMM (Automated Market Maker) where pool reserves and trades are encrypted on-chain. Arbitrageurs or front-runners cannot exploit the pool because they can’t observe the price slippage until after the trade is settled, reducing MEV. Only after some delay or via an access-controlled mechanism might some data be revealed for audit.

  • MEV-Resistant Auctions and Trading: Miners and bots exploit transaction transparency to front-run trades. With encryption, you could have an encrypted mempool or batch auctions where orders are submitted in ciphertext. Only after the auction clears do trades decrypt. This concept, sometimes called Fair Order Flow, can be achieved with threshold decryption (multiple validators collectively decrypt the batch) or by proving auction outcomes via ZK without revealing individual bids. For instance, a ZK-coprocessor could take a batch of sealed bids off-chain, compute the auction clearing price, and output just that price and winners with proofs. This preserves fairness and privacy of losing bids.

  • Confidential Lending and Derivatives: In DeFi lending, users might not want to reveal the size of their loans or collateral (it can affect market sentiment or invite exploitation). An FHE-VM can maintain an encrypted loan book where each loan’s details are encrypted. Smart contract logic can still enforce rules like liquidation conditions by operating on encrypted health factors. If a loan’s collateral ratio falls below threshold, the contract (with help of ZK proofs) can flag it for liquidation without ever exposing exact values – it might just produce a yes/no flag in plaintext. Similarly, secret derivatives or options positions could be managed on-chain, with only aggregated risk metrics revealed. This could prevent copy trading and protect proprietary strategies, encouraging more institutional participation.

  • Compliant Privacy: Not all financial contexts want total anonymity; sometimes selective disclosure is needed for regulation. With these tools, we can achieve regulated privacy: for example, trades are private to the public, but a regulated exchange can decrypt or receive proofs about certain properties. One could prove via ZK that “this trade did not involve a blacklisted address and both parties are KYC-verified” without revealing identities to the chain. This balance could satisfy Anti-Money Laundering (AML) rules while still keeping user identities and positions confidential to everyone else. FHE could allow an on-chain compliance officer contract to scan encrypted transactions for risk signals (with a decryption key accessible only under court order, for instance).

Digital Identity and Personal Data

Identity systems stand to gain significantly from on-chain privacy tech. Currently, putting personal credentials or attributes on a public ledger is impractical due to privacy laws and user reluctance. With FHE and ZK, self-sovereign identity can be realized in a privacy-preserving way:

  • Zero-Knowledge Credentials: Using ZK proofs (already common in some identity projects), a user can prove statements like “I am over 18”, “I have a valid driver’s license”, or “I earn above $50k (for credit scoring)” without revealing any other personal info. ZK-coprocessors can enhance this by handling more complex checks off-chain, e.g. proving a user’s credit score is above a threshold by querying a private credit database in an Axiom-like fashion, outputting only a yes/no to the blockchain.

  • Confidential KYC on DeFi: Imagine a DeFi protocol that by law must ensure users are KYC’d. With FHE-VM, a user’s credentials can be stored encrypted on-chain (or referenced via DID), and a smart contract can perform an FHE computation to verify the KYC info meets requirements. For instance, a contract could homomorphically check that name and SSN in an encrypted user profile match a sanctioned users list (also encrypted), or that the user’s country is not restricted. The contract would only get an encrypted “pass/fail” which can be threshold-decrypted by network validators to a boolean flag. Only the fact that the user is allowed or not is revealed, preserving PII confidentiality and aligning with GDPR principles. This selective disclosure ensures compliance and privacy.

  • Attribute-Based Access and Selective Disclosure: Users could hold a bunch of verifiable credentials (age, citizenship, skills, etc.) as encrypted attributes. They can authorize certain dApps to run computations on them without disclosing everything. For example, a decentralized recruitment DApp could filter candidates by performing searches on encrypted resumes (using FHE) – e.g. count years of experience, check for a certification – and only if a match is found, contact the candidate off-chain. The candidate’s private details remain encrypted unless they choose to reveal. ZK proofs can also let users selectively prove they possess a combination of attributes (e.g. over 21 and within a certain ZIP code) without revealing the actual values.

  • Multi-Party Identity Verification: Sometimes a user’s identity needs to be vetted by multiple parties (say, background check by company A, credit check by company B). With homomorphic and ZK tools, each verifier could contribute an encrypted score or approval, and a smart contract can aggregate these to a final decision without exposing individual contributions. For instance, three agencies provide encrypted “pass/fail” bits, and the contract outputs an approval if all three are passes – the user or relying party only sees the final outcome, not which specific agency might have failed them, preserving privacy of the user’s record at each agency. This can reduce bias and stigma associated with, say, one failed check revealing a specific issue.

Healthcare and Sensitive Data Sharing

Healthcare data is highly sensitive and regulated, yet combining data from multiple sources can unlock huge value (for research, insurance, personalized medicine). Blockchain could provide a trust layer for data exchange if privacy is solved. Confidential smart contracts could enable new health data ecosystems:

  • Secure Medical Data Exchange: Patients could store references to their medical records on-chain in encrypted form. An FHE-enabled contract could allow a research institution to run analytics on a cohort of patient data without decrypting it. For example, a contract could compute the average efficacy of a drug across encrypted patient outcomes. Only aggregate statistical results come out decrypted (and perhaps only if a minimum number of patients is included, to prevent re-identification). Patients could receive micropayments for contributing their encrypted data to research, knowing that their privacy is preserved because even the blockchain and researchers only see ciphertext or aggregate proofs. This fosters a data marketplace for healthcare that respects privacy.

  • Privacy-Preserving Insurance Claims: Health insurance claims processing could be automated via smart contracts that verify conditions on medical data without exposing the data to the insurer. A claim could include an encrypted diagnosis code and encrypted treatment cost; the contract, using FHE, checks policy rules (e.g. coverage, deductible) on that encrypted data. It could output an approval and payment amount without ever revealing the actual diagnosis to the insurer’s blockchain (only the patient and doctor had the key). ZK proofs might be used to show that the patient’s data came from a certified hospital’s records (using something like Axiom to verify a hospital’s signature or record inclusion) without revealing the record itself. This ensures patient privacy while preventing fraud.

  • Genomic and Personal Data Computation: Genomic data is extremely sensitive (it’s literally one’s DNA blueprint). However, analyzing genomes can provide valuable health insights. Companies could use FHE-VM to perform computations on encrypted genomes uploaded by users. For instance, a smart contract could run a gene-environment risk model on encrypted genomic data and encrypted environmental data (from wearables perhaps), outputting a risk score that only the user can decrypt. The logic (maybe a polygenic risk score algorithm) is coded in the contract and runs homomorphically, so the genomic data never appears in plain. This way, users get insights without giving companies raw DNA data – mitigating both privacy and data ownership concerns.

  • Epidemiology and Public Health: During situations like pandemics, sharing data is vital for modeling disease spread, but privacy laws can hinder data sharing. ZK coprocessors could allow public health authorities to submit queries like “How many people in region X tested positive in last 24h?” to a network of hospitals’ data via proofs. Each hospital keeps patient test records off-chain but can prove to the authority’s contract the count of positives without revealing who. Similarly, contact tracing could be done by matching encrypted location trails: contracts can compute intersections of encrypted location histories of patients to identify hotspots, outputting only the hotspot locations (and perhaps an encrypted list of affected IDs that only health dept can decrypt). The raw location trails of individuals remain private.

Data Marketplaces and Collaboration

The ability to compute on data without revealing it opens new business models around data sharing. Entities can collaborate on computations knowing their proprietary data will not be exposed:

  • Secure Data Marketplaces: Sellers can make data available in encrypted form on a blockchain marketplace. Buyers can pay to run specific analytics or machine learning models on the encrypted dataset via a smart contract, getting either the trained model or aggregated results. The seller’s raw data is never revealed to the buyer or the public – the buyer might only receive a model (which still might leak some info in weights, but techniques like differential privacy or controlling output granularity can mitigate this). ZK proofs can ensure the buyer that the computation was done correctly over the promised dataset (e.g. the seller can’t cheat by running the model on dummy data because the proof ties it to the committed encrypted dataset). This scenario encourages data sharing: for instance, a company could monetize user behavior data by allowing approved algorithms to run on it under encryption, without giving away the data itself.

  • Federated Learning & Decentralized AI: In decentralized machine learning, multiple parties (e.g. different companies or devices) want to jointly train a model on their combined data without sharing data with each other. FHE-VMs excel here: they can enable federated learning where each party’s model updates are homomorphically aggregated by a contract. Because the updates are encrypted, no participant learns others’ contributions. The contract could even perform parts of the training loop (like gradient descent steps) on-chain under encryption, producing an updated model that only authorized parties can decrypt. ZK can complement this by proving that each party’s update was computed following the training algorithm (preventing a malicious participant from poisoning the model). This means a global model can be trained with full auditability on-chain, yet the training data of each contributor remains private. Use cases include jointly training fraud detection models across banks or improving AI assistants using data from many users without centralizing the raw data.

  • Cross-Organizational Analytics: Consider two companies that want to find their intersection of customers for a partnership campaign without exposing their entire customer lists to each other. They could each encrypt their customer ID lists and upload a commitment. An FHE-enabled contract can compute the intersection on the encrypted sets (using techniques like private set intersection via FHE). The result could be an encrypted list of common customer IDs that only a mutually trusted third-party (or the customers themselves, via some mechanism) can decrypt. Alternatively, a ZK approach: one party proves to the other in zero-knowledge that “we have N customers in common and here is an encryption of those IDs” with a proof that the encryption indeed corresponds to common entries. This way, they can proceed with a campaign to those N customers without ever exchanging their full lists in plaintext. Similar scenarios: computing supply chain metrics across competitors without revealing individual supplier details, or banks collating credit info without sharing full client data.

  • Secure Multi-Party Computation (MPC) on Blockchain: FHE and ZK essentially bring MPC concepts on-chain. Complex business logic spanning multiple organizations can be encoded in a smart contract such that each org’s inputs are secret-shared or encrypted. The contract (as an MPC facilitator) produces outputs like profit splits, cost calculations, or joint risk assessments that everyone can trust. For example, suppose several energy companies want to settle a marketplace of power trading. They could feed their encrypted bids and offers into a smart contract auction; the contract computes the clearing prices and allocations on encrypted bids, and outputs each company’s allocation and cost just to that company (via encryption to their public key). No company sees others’ bids, protecting competitive info, but the auction result is fair and verifiable. This combination of blockchain transparency and MPC privacy could revolutionize consortiums and enterprise consortia that currently rely on trusted third parties.

Decentralized Machine Learning (ZKML and FHE-ML)

Bringing machine learning to blockchains in a verifiable and private way is an emerging frontier:

  • Verifiable ML Inference: Using ZK proofs, one can prove that “a machine learning model f, when given input x, produces output y” without revealing either x (if it’s private data) or the inner workings of f (if the model weights are proprietary). This is crucial for AI services on blockchain – e.g., a decentralized AI oracle that provides predictions or classifications. A ZK-coprocessor can run the model off-chain (since models can be large and expensive to evaluate) and post a proof of the result. For instance, an oracle could prove the statement “The satellite image provided shows at least 50% tree cover” to support a carbon credit contract, without revealing the satellite image or possibly even the model. This is known as ZKML and projects are working on optimizing circuit-friendly neural nets. It ensures the integrity of AI outputs used in smart contracts (no cheating or arbitrary outputs) and can preserve confidentiality of the input data and model parameters.

  • Training with Privacy and Auditability: Training an ML model is even more computation-intensive, but if achievable, it would allow blockchain-based model marketplaces. Multiple data providers could contribute to training a model under FHE so that the training algorithm runs on encrypted data. The result might be an encrypted model that only the buyer can decrypt. Throughout training, ZK proofs could be supplied periodically to prove that the training was following the protocol (preventing a malicious trainer from inserting a backdoor, for example). While fully on-chain ML training is far off given costs, a hybrid approach could use off-chain compute with ZK proofs for critical parts. One could imagine a decentralized Kaggle-like competition where participants train models on private datasets and submit ZK proofs of the model’s accuracy on encrypted test data to determine a winner – all without revealing the datasets or the test data.

  • Personalized AI and Data Ownership: With these technologies, users could retain ownership of their personal data and still benefit from AI. For example, a user’s mobile device could use FHE to encrypt their usage data and send it to an analytics contract which computes a personalized AI model (like a recommendation model) just for them. The model is encrypted and only the user’s device can decrypt and use it locally. The platform (maybe a social network) never sees the raw data or model, but the user gets the AI benefit. If the platform wants aggregated insights, it could request ZK proofs of certain aggregate patterns from the contract without accessing individual data.

Additional Areas

  • Gaming: On-chain games often struggle with hiding secret information (e.g. hidden card hands, fog-of-war in strategy games). FHE can enable hidden state games where the game logic runs on encrypted state. For example, a poker game contract could shuffle and deal encrypted cards; players get decryptions of their own cards, but the contract and others only see ciphertext. Betting logic can use ZK proofs to ensure a player isn’t bluffing about an action (or to reveal the winning hand at the end in a verifiably fair way). Similarly, random seeds for NFT minting or game outcomes can be generated and proven fair without exposing the seed (preventing manipulation). This can greatly enhance blockchain gaming, allowing it to support the same dynamics as traditional games.

  • Voting and Governance: DAOs could use privacy tech for secret ballots on-chain, eliminating vote buying and pressure. FHE-VM could tally votes that are cast in encrypted form, and only final totals are decrypted. ZK proofs can assure each vote was valid (came from an eligible voter, who hasn’t voted twice) without revealing who voted for what. This provides verifiability (everyone can verify the proofs and tally) while keeping individual votes secret – crucial for unbiased governance.

  • Secure Supply Chain and IoT: In supply chains, partners might want to share proof of certain properties (origin, quality metrics) without exposing full details to competitors. For instance, an IoT sensor on a food shipment could continuously send encrypted temperature data to a blockchain. A contract could use FHE to check if the temperature stayed in a safe range throughout transit. If a threshold was exceeded, it can trigger an alert or penalty, but it doesn’t have to reveal the entire temperature log publicly – maybe only a proof or an aggregate like “90th percentile temp”. This builds trust in supply chain automation while respecting confidentiality of process data.

Each of these use cases leverages the core ability: compute on or verify data without revealing the data. This capability can fundamentally change how we handle sensitive information in decentralized systems. It reduces the trade-off between transparency and privacy that has limited blockchain adoption in areas dealing with private data.

Conclusion

Blockchain technology is entering a new era of programmable privacy, where data confidentiality and smart contract functionality go hand in hand. The paradigms of FHE-VM and ZK-coprocessors, while technically distinct, both strive to expand the scope of blockchain applications by decoupling what we can compute from what we must reveal.

Fully Homomorphic Encryption Virtual Machines keep computations on-chain and encrypted, preserving decentralization and composability but demanding advances in efficiency. Zero-Knowledge coprocessors shift heavy lifting off-chain, enabling virtually unbounded computation under cryptographic guarantees, and are already proving their worth in scaling and enhancing Ethereum. The choice between them (and hybrids thereof) will depend on the use case: if real-time interaction with private state is needed, an FHE approach might be more suitable; if extremely complex computation or integration with existing code is required, a ZK-coprocessor might be the way to go. In many cases, they are complementary – indeed, we see ZK proofs bolstering FHE integrity, and FHE potentially helping ZK by handling private data for provers.

For developers, these technologies will introduce new design patterns. We will think in terms of encrypted variables and proof verification as first-class elements of dApp architecture. Tooling is rapidly evolving: high-level languages and SDKs are abstracting away cryptographic details (e.g. Zama’s libraries making FHE types as easy as native types, or RISC Zero’s templates for proof requests). In a few years, writing a confidential smart contract could feel almost as straightforward as writing a regular one, just with privacy “built-in” by default.

The implications for the data economy are profound. Individuals and enterprises will be more willing to put data or logic on-chain when they can control its visibility. This can unlock cross-organization collaborations, new financial products, and AI models that were previously untenable due to privacy concerns. Regulators, too, may come to embrace these techniques as they allow compliance checks and audits via cryptographic means (e.g. proving taxes are paid correctly on-chain without exposing all transactions).

We are still in the early days – current FHE-VM prototypes have performance limits, and ZK proofs, while much faster than before, can still be a bottleneck for extremely complex tasks. But continuous research and engineering efforts (including specialized hardware, as evidenced by companies like Optalysys pushing optical FHE acceleration) are quickly eroding these barriers. The funding pouring into this space (e.g. Zama’s unicorn status, Paradigm’s investment in Axiom) underscores a strong belief that privacy features will be as fundamental to Web3 as transparency was to Web1/2.

In conclusion, programmable privacy via FHE-VMs and ZK-coprocessors heralds a new class of dApps that are trustless, decentralized, and confidential. From DeFi trades that reveal no details, to health research that protects patient data, to machine learning models trained across the world without exposing raw data – the possibilities are vast. As these technologies mature, blockchain platforms will no longer force the trade-off between utility and privacy, enabling broader adoption in industries that require confidentiality. The future of Web3 is one where *users and organizations can confidently transact and compute with sensitive data on-chain, knowing the blockchain will verify integrity while keeping their secrets safe*.

Sources: The information in this report is drawn from technical documentation and recent research blogs of leading projects in this space, including Cypher’s and Zama’s FHEVM documentation, detailed analyses from Trail of Bits on Axiom’s circuits, RISC Zero’s developer guides and blog posts, as well as industry articles highlighting use cases of confidential blockchain tech. These sources and more have been cited throughout to provide further reading and evidence for the described architectures and applications.