Colibri
Colibri is a tool to create verifiable omni-chain balances.Colibri works with Risc0 and IPC. Users need to create a wrapped token representing the balance of a user for a certain token, then Colibri asks risc0 to create a proof of balance.
Project Description
Colibri works with Risc0 and IPC. Users need to create a wrapped token representing the balance of a user for a certain token.
Then Colibri asks risc0 to create a proof of balance.
Colibri wirtes the Balance to an IPC subnet, created ad-hoc for this reason. This subnet is highly customizable and it's perfect for this scope.
On other chains, colibri asks risc0 again to verify the balances on all the other chain and IPC subnets.
More detailed info (read this if you're a nerd) Colibri has a system where a bunch of colibri-wrapper contracts are deployed on various networks. (In our case we use few testnet networks like sepolia and base).
We also leverage IPC custom subnet to use as a unified ledger, storing omnichain balances.
Every time an asset gets wrapped the user will need a risc0+bonsai operation to return a snark required for the transaction to go trough.
The risc0 proofs are needed for reading data across chains and have a sort of proof that a given view call has been performed, these are ultimately converted from stark2snark and returned to our application so he can either write on balance or prompt a transaction for the user.
The goal of the project is to create a provable omnichain balance and seek alternatives in bridging operations, ultimately trying to achieve such in just a tx on the destination chain, without having to interpel the fromChain
How it's Made
So we basically try to have a system where colibri-wrapper contracts are deployed on various networks. (In our case we use few testnet networks) We also have a filecoin custom network to leverage for storing omnichain balances. Every time an asset gets bridged the user will need a risc0+bonsai operation to return a snark required for the transaction to go trough.
The risc0 proofs are needed for reading data across chains and have a sort of proof that a given view call has been performed, these are ultimately converted from stark2snark and returned to our application so he can either write on balance or prompt a transaction for the user.
The goal of the project is to seek alternatives in bridging operations, ultimately trying to achieve such in just a tx on the destination chain, without having to interpel the fromChain, offloading some ecosystem gas cost in ipc
