# [Shared] Uniswap Foundation Cross-Chain Bridge Assessment

Hi all,

Uma from [Succinct](https://succinct.xyz/) here. We're building a cross-chain interoperability solution secured with zkSNARKs that is significantly more decentralized, permissionless and censorship resistant compared to existing bridging solutions. While our protocol has not been deployed to mainnet as of right now, we plan on deploying our protocol to mainnet quite soon and I wanted to post in this forum, if not for official consideration, then to raise awareness of a new generation of bridging solutions that are highly aligned with the decentralization, permissionless and censorship resistant properties that Uniswap governance cares about.

For some background on the general principal of light-client bridging enabled by zkSNARKs, here is an informational blog post that our team wrote: https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus/ about the general idea.

1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
1. Uniswap as a protocol fiercely cares about decentralization, censorship resistance and permissionlessness. This is evident in the deployment of all versions of the core protocol as non-upgradeable contracts with DAO-controlled voting for any protocol-level changes. Current bridging solutions that rely on permissioned multisigs or PoS validator sets *do not* inherit the underlying security of Ethereum and compromise on many of Uniswap's core values. We believe that on-chain succinct light clients powered by zkSNARK technology is the first time it's possible for a bridging solution to align fully with Uniswap's core values.
2. Permissioned multisigs that back most existing bridges can forge fraudulent messages or censor valid messages. Permissionless, on-chain systems that verify the consensus of a source chain in the execution layer of a target chain are censorship resistant and not forgeable.
3. As highlighted in the blog-post [linked to above](https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus/ ), we believe that zkSNARK-enabled succinct light clients are the **end-game** of cross-chain interoperability. Some of the cons of zkSNARK bridging currently include that it is slower than normal multisig bridging and costs more gas (due to the need to verify a zk proof on-chain vs. the minimal cost of verifying signatures from a multisig). For the governance use-case, where latency and gas-costs are relatively unimportant (as governance has a timelock anyways and messages are infrequent), the cons of zkSNARK bridging are not relevant.

2. How long has the system been running on mainnet?
* Our system is not currently deployed on mainnet, as we are working with relatively newer technology (zkSNARKs) compared to the rest of the bridging landscape. Our current plan for mainnet deployment is quite soon (we have already deployed a system to testnet and are stress-testing it before our mainnet launch) and we believe that Uniswap governance should consider us as a viable solution in the near-term future.

3. How much value has the system secured? (Current TVL, total transaction volume)
* N/A for aforementioned reasons

4. Provide a background on your team.
* The assembled team has deep expertise in zkSNARKs, blockchain and consensus. The core engineering team has experience from some of the best academic institutions (MIT, Stanford, UC Berkeley) and professional experience from top-tier engineering and technology companies, including Google, Celo, NVIDIA, and Plaid. Additionally, our team and company originated from collaboration with idealogically aligned ecosystem partners, such as [0xPARC](https://0xparc.org/about) and Gnosis DAO, who generously gave us a [grant that got us our start](https://forum.gnosis.io/t/gip-57-should-gnosis-dao-support-research-of-a-zksnark-enabled-light-client-and-bridge/5421).

5. Please link your developer documentation.
* Our initial documentation is being updated in real-time before our mainnet launch but an early (very rough draft) version with some of the interfaces is available here: https://docs.succinct.xyz/build-with-telepathy/arbitrary-messaging

6. Does the bridge support arbitrary message passing?
* Yes this is the only thing our bridge supports right now and our main focus as a company.

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?
* We have engaged 3 audit firms to audit our system end-to-end. These audit reports will be public prior to our mainnet launch.
* Veridise is a premier zkSNARK auditing firm that also does formal verification of circuits. Veridise has audited our zkSNARK circuits at the heart of our system.
* Trail of Bits is a top-tier blockchain security firm that audited our zkSNARK circuits and smart contracts.
* Zellic is another top-tier auditor that we have engaged for our smart contracts.

8. Is there a bug bounty program?
* We plan on having a generous bug bounty program with Immunifi once our mainnet deployment goes live.

9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
* Our system is secured by an Ethereum light client running on-chain. The core light client is permissionless: it is not upgradeable and has no owner. Anyone can submit header updates to the light client and the updates are validated by the zkSNARK proof validation.
* The messaging protocol that uses the on-chain Ethereum light client is permissionless (anyone can submit messages), as the messages are validated against headers from the light client to verify they were actually sent on Ethereum. The messaging protocol is configurable and flexible to have whatever upgradeability pattern (or lack thereof) that the user desires, and our mainnet deployment will have a few different options for users to select between.

10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?
* Addressed above.

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?
* The security model for this bridge is light client security. At a high-level we are trusting the honesty of the Ethereum validators involved in the Ethereum light client protocol. Like all other bridging protocols, the security model also includes correct implementation of the protocol as an assumption. More details about the protocol and its trust assumptions can be found here: https://docs.succinct.xyz/protocol/overview.

12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
* Like any bridge, if there are implementation bugs then the adversary can pass fraudulent messages if they hack the implementation of our system.
* If the adversary is able to systematically bribe Ethereum validators to compromise Ethereum's light client protocol (extremely unlikely), they will also be able to trasmit a fraudulent header.
13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
* Similar to above, if there are implementation bugs or if an adversary is able to systematically bribe Ethereum validators to compromise Ethereum's light client protocol and bribe them to not sign a series of valid headers (which is extremely unlikely).

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.
* N/A to our system as it is permissionless

15. Provide any additional information you would like here.
* We encourage Uniswap governance to consider a new generation of bridging solutions powered by on-chain Succinct light clients and zkSNARKs that are able to provide much of the security properties they care about.