Proving Mechanism

Leveraging light clients for validation alongside a collateral-based architecture allows resolvers to utilize their capital efficiently for executing swap operations. In an effort to minimize gas costs, Flash Trade implements a delayed batch validation mechanism. As a result, the process of swapping funds consists of two (send and receive) extremely cost-effective p2p transactions (slightly more expensive than a regular token transfer due to order structure verification and custom smart-contract events). The resolver can execute such operations to the extent that their collateral allows. Collateral is "locked" for each operation (means that the counter of the swapped volume in the receive network increases, ensuring it does not exceed the volume of the resolver's collateral). When no more collateral is available, the resolver needs to “unlock” it.

Thus, the sequence of actions looks like this:

1. Collateral deposit, initializing unlockedCollateral counter in a proof network;

2. Setting unlockedCollateral in the order structure;

3. Placing an order that increases the lockedCollateral counter in a receive network;

4. Filling order in a send network;

5. Repeat while lockedCollateral < unlockedCollateral;

6. Batch proving with multiple proofs of receive and send transactions, which increases the value of unlockedCollateral counter;

7. Repeat the cycle the required number of times (starting from p.2).

Transaction confirmation is the process of calling the confirmOrderAssetSend method in the OrderResolver contract with the transfer of two types of proofs: receiveProof and sendProof.

Proof verifies that a certain EVM event with specific data has indeed occurred on some chain. The proof events used for all swap scenarios are produced on chains where assets are received and sent and consumed by the collateral manager.

Proofs are transferred to the corresponding ProofVerifier contract, which must check the validity of the proof and confirm the event that occurred (sending or receiving funds).

The OrderResolver contract serves to manage resolver collaterals for swap insurance. This contract supports both the deposit and withdrawal of the authorized collateral assets (ERC-20 stable tokens) by resolvers and methods for resolving order states, either as successfully completed or slashed in favor of a liquidator or user. The resolving is based on corresponding proof verification by the constructor-initialized proof verifier contract (IProofVerifier).

Currently, three types of proofers are supported: local state, event-bridge (Hashi-based), and light clients.

Local State Proof verifier

LocalStateProofVerifier serves to prove events that occurred on the same chain where this proof verifier is deployed. It is capable of proving any event by using view methods of the constructor-initialized address of the state source contract (i.e. KinetexFlash, KinetexFlashLight) on the same chain.

Event-bridge (Hashi-based)

The EventBridgeProofVerifier contract serves for proving events that occurred on a chain different from the one on which this proof verifier is deployed. This is achieved by delivering event information from one chain to another using cross-chain transport protocols aggregated by Hashi. The verifier is initialized with the Hashi contract address, which aggregates received event information from multiple pre-configured cross-chain messaging systems with a certain threshold to enhance proving security and robustness.

Light Client verifier

The most efficient gas-wise, this verifier verifies events in the send/receive network through a light client contract located in the proving network.

Verification through light clients, unlike the classic cross-chain flow, does not involve calling transactions in send/receive networks. The use of ZK technology, in combination with checkpoint-based updating of light clients using Merkle trees or MMR for blockchain data storage, enables validating completed swap operations as efficiently and securely as possible.

Proof Routing

The Flash Trade architecture allows it to redirect different types of proofs to different proof verifiers using the ProofVerifierRouterFossil contract, which aggregates multiple proof verifier variants. Proof verifiers' routes are configured in the constructor in an immutable manner. When requested to verify proof as an IProofVerifier implementor, the router gets a configured proof verifier for the requested proof chain and proof variant passed in ProofHeader. Then the router either rejects the proof if no route is configured or proceeds by calling the corresponding proofer and passing the whole proof.