Nominating ChainPort for UNI Cross-Chain Support
1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
A. ChainPort employs full fund segragation, meaning contracts operating the bridge hold only an operating budget, and over 95% of funds are secured by MPC (Fireblocks) and/or Multi-Sig Vault Contracts (Gnosis).
B. ChainPort enables a customized custodian solution, which can enable the Uniswap DAO to act as signatory holding and managing the frozen tokens in the MPC and/or Multi-Sig Vaults. This means the community/DAO can act as a requires layer of security for keeping the origin UNI safe and out of circulation while that supply is mirrored on the target chains.
C. On target chains, the mintable tokens created by ChainPort have various security mechanisms which can be delegated to the control of the UNI Governance DAO.
2. How long has the system been running on mainnet?
App.ChainPort.io has been live since May 2021. You can view stats for last 12 months on our stats page
3. How much value has the system secured? (Current TVL, total transaction volume)
Currently:
~170M$ TVL
605.46M$ Lifetime Port Volume
66,586 Ports to date
More stats on the stats page.
4. Provide a background on your team.
ChainPort is built and maintained by DcentraLab,
you can meet our team on Linkedin
5. Please link your developer documentation.
6. Does the bridge support arbitrary message passing?
no, only token transfers currently. Arbitrary message passing is currently not in a mature enough state in terms of security,
hence all other bridges getting hacked on the protocol level…
Nevertheless we are working on a 2.0 version with more generalized messaging framework, and will release it once we believe it will not require bug iterations on the backs of production users and funds…
7. Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
The first audit was made by CyberUnitTech:
ChainPort CyberUnitTech Audit
You can review quite a few of the more updated audits made by Certik here: ChainPort Certik Audits
We also have a TrailOfBits 8 Engineering week audit performed on the backend and contracts code, which has just been concluded and we’d be happy to share it with the assessment team (it is not available online).
In all audits, any medium and up issues have been resolved, and all pertinent or actual low and below issues as well. The major vulnerability in a custodian bridge solution is the custodianship, which we resolve by multiple layers of security and segregated permissions, including also the project representatives, and our own DAO congresses and distributed multi-sig schemas.
You can read more about our security approach here: ChainPort Security
8. Is there a bug bounty program?
We’re in final stages of installing it. Running in the past we’ve seen it become very spammy, we’re working on a refined methodology for getting actual value of the program.
9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
as discussed the funds themselves are 95% in gnosis vaults and/or Fireblocks MPC vaults (per the preferences of the project, e.g. UNI governance can decide where to store the origin UNI frozen on source chain). The target token is upgradable and governable by either a congress of DcentraLab representatives, or a congress of DcentraLab reps and UNI reps, or by UNI Governance reps directly.
- Gnosis vaults are upgradable but will require signature of UNI DAO as well
- Target Tokens (UNI on target chains) can be set to be governable and upgradable only by approval/signature from UNI DAO.
- The contracts (main bridge and side bridge) operating the bridging itself, hold 5% or less of the supply (for main bridge), or have a minting capability which can be set to be frozen by the UNI DAO in cases of emergency. These 2 contracts are upgradable by a DcentraLab DAO congress vote (a cold wallet multi-sig contract schema of geo distributed representatives.
10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?
The bridge contracts have the DcentraLab Congress as governer.
The bridged tokens contracts has a dedicated Congress as controller, which can also be set to be a dedicated congress with UNI DAO reps included or a UNI DAO contract included as signer.
Congresses can perform security actions as unfreezing the bridge after security mechanisms trigger freezing, or making security operations on the tokens (freezing/unfreezing tokens, freezing/unfreezing accounts etc…)
11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?
For the custom custody model, we remove most trust assumptions, and enable the project/DAO itself (in this case UNI DAO) to trust only itself for the majority of financially risky operations:
- UNI DAO signature will be required along with the DcentraLab Congress to free up UNI reserves (rebalance bridge) - which means the TVL will be guarded directly ALSO by UNI DAO (in addition to the DcentraLab Congress).
- UNI DAO signature will be allowed to freeze minted tokens on side/target chains.
- UNI DAO signature will be required to unfreeze token in case of freeze, and will be able to freeze token or minting of the token,
- UNI DAO signature will be required to upgrade side chain tokens.
- UNI DAO will be able to run your own version of the bridge monitor, to auto-freeze minting and the token in case a discrepancy in the accounting/minting takes place (e.g. minted appear as higher then deposited amounts cross the network etc…)
12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
The ChainPort system only accepts messages from the chainport contracts, so the only way to pass a fraudulent message would be to somehow take over the chainport contracts themselves (i.e. get physical access to a majority of the DAO signers). Even then, UNI DAO will have control over the reserves, and minting, and the tokens on target chains, so no real damage can be accrued and minting + the tokens can be frozen in such unlikely case until it is resolved.
13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
In the current system, this can be possible if a malicious actor hacked many layers of server security and somehow took down the backend. But once the backend has redundancy mechanism so this is unlikely. But even in such case, once backend is back online it will continue processing messages where left of. As soon as valid event is emitted, it will eventually be processed.
14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.
We don’t rely or depend on external actors, only on direct interest actors, in this case, the UNI DAO will partake in the security, so is serving a self-interest in protecting the UNI cross-chain network.
15. Provide any additional information you would like here.
You can read more about the custom custodian solution here: ChainPort Custom Custody Solution for DAOs/Projects
We are working on ChainPort 2.0 which will offer generalized cross chain messaging and a more decentralized message relay, validation and verification mechanisms.
We believe that the other currently available more “Decentralized” solutions are premature and much more prone to hacking, which is why our approach is to very slowly decentralize, while keeping security as main concern.
We are also now supporting Cardano utilizing a highly secure approach, which also enables the UNI DAO to govern and control the entire minted supply on Cardano in a DAO like manner, for enhanced security. We can share more on this in a dedicated discussion.