Non-EVM Networks

Integrating light clients for validation within a collateral-based architecture provides a unique opportunity to leverage capabilities of the EVM (the Ethereum Virtual Machine) networks for connecting non-EVM networks like Solana, Tron, and even networks without smart-contract logic such as Bitcoin, Cardano, Ripple, etc.


Bitcoin uses a Proof-of-Work (PoW) consensus mechanism and lacks support for smart contracts, making integrating with the DeFi ecosystem of Ethereum and other networks challenging. Due to Bitcoin's limited scripting capabilities, the swapping scheme differs significantly from the default implementation through OrderSender or OrderReceiver contracts. Instead, the logic for validating and recording the swap state relies on the EVM-like send or receive (depending on the direction) and proof networks, requiring signatures from both a user and a resolver.

At the moment, Kinetex is actively working on a ZK light client for Bitcoin, which is based on BTC-Warp project and uses Plonky2 proof conversion with subsequent verification through the Groth16 verifier. It will allow checking Bitcoin network transactions in any EVM-like network through a light client contract.

Unlike light clients for PoS/DPoS networks, which mainly validate validators' signatures, this one checks if proposed updates match the current network difficulty. Since the strongest chain will always be considered correct, it is essential to maintain the current state of the Bitcoin light client by providing valid data from trusted sources.


Unlike Ethereum, Solana does not use the EVM to execute smart contracts. Solana smart contracts, typically written in languages like Rust or C, are compiled into machine code that runs directly on the Solana blockchain by the SVM (the Solana Virtual Machine). Integrating Solana to the Flash Trade protocol requires porting the logic of OrderSender and OrderReceiver solidity contracts to Solana-supported languages.

The main challenge is creating a proof verifier for validating transactions in Solana. Thus, it is necessary to connect event-bridge transports that support the validation of Solana network events or implement the logic of the Solana light client (for example, Tinydancer) using ZK technology.


Tron uses the Tron Virtual Machine (TVM) to execute smart contracts. TVM is a runtime environment that interprets the bytecode of smart contracts and executes the instructions on the Tron blockchain. It is compatible with the EVM allowing developers to migrate existing Ethereum smart contracts to Tron with minimal modifications. A few minor modifications are required to make OrderSender and OrderReceiver contracts available on Tron.

Currently, there is a lack of solutions for arbitrary cross-chain message protocols between Tron and Ethereum. As a result, the most reliable option would be to create a Tron light client using ZK technology. Tron utilizes a DPoS consensus mechanism, where token holders elect a set of delegates to validate transactions and produce new blocks. These delegates are responsible for reaching a consensus on the state of the blockchain. Thus, the implementation of a light client must fully implement the logic of selecting validators and checking their signatures.

Last updated