Vector 0.1.0 Mainnet Release
The beginning of a multi-chain Ethereum ecosystem
TL;DR:
We shipped the thing! Check out our docs to get started supporting crosschain transfers in your dApp. Trust assumptions and details below.
After months of hard work, we’re incredibly excited to announce the 0.1.0 mainnet release of Vector! 🎉
This marks the start of the multi-chain Ethereum ecosystem, where users can seamlessly interact with wallets and applications running on a variety of different L2s and shards, all without ever needing to know it’s happening.
↗️ A Quick Recap of Vector
Back in November, we unveiled our vision of Connext as a cross-chain routing network for Ethereum L2s and shards. Vector, our flagship implementation of this network, uses state channels to enable swapping value between chains through a network of intermediary liquidity providers called routers.
This means you can use Vector to:
- Instantly enter and exit, circumventing withdraw windows, into any Ethereum L2, shard, or turing-complete chain.
- Send value (and soon even call contracts) between L2 ecosystems. For instance, using Uniswap running on Optimism with assets on Arbitrum.
- Execute normal state channel usecases like conditional micropayments.
📦 Mainnet Deployment Details
Contracts have been deployed to the Ethereum mainnet at the following addresses:
As mentioned in our last post, the contracts have been fully audited by Chainsafe. A security review of the offchain protocol is pending and will be completed before the end of Q1.
⚠️ While the team is confident in the implementation and has failsafes to ensure that user funds can always be recovered, this release should still be treated as an alpha! ⚠️
👷 Developers and Dapp Integrations
Builders can integrate Vector into their applications and protocols to enable conditional micropayments and enable seamless L2 on/offboarding. There’s a few ways to develop against Vector:
- Browser-node: Vector protocol implementation meant for browser environments. Contains built-in functionality for key management using iframes.
- Server-node: Vector protocol implementation meant for backend environments. Accepts inbound connections via REST and gRPC interfaces.
- Widget [Coming soon!]: Drop-in web component that can be easily integrated into any dApp to let users send funds across chains.
If you’re unsure where to get started, check out our docs or hit us up in discord.
🔐 Trust Assumptions and Considerations
Our philosophy is to be as transparent as possible about potential trust and centralization vectors while we progressively work to mitigate them.
Custody Risk on Users and Routers
Using Connext is entirely noncustodial. There is no way for the Connext team or any routers within the network to steal your funds or stop you from exiting the system so long as you (a) have access to your offchain state, and (b) are able to come online to resolve disputes.
Risk of Unavailability or Losing State
As with any state channel protocol, it is important to consider what happens if you lose your offchain state or cannot be online in the event of a dispute. Vector allows 3rd parties (called Watchtowers) to back up your state and respond to disputes on your behalf. Watchtowers let end users run “light client” versions of channels where they store minimal data and can go offline.
It’s possible to back up state and run watchtowers today. We have eventual plans to economically incentivize this activity as part of the network’s operation. As a failsafe while bootstrapping, we also intend to run a global watchtower ourselves.
Censorship Risk on Routers
It is possible for routers that facilitate transfers to censor users. There are several ways by which this concern can get mitigated in the long run.
We can mitigate the risk of selective censorship by reducing the information gleanable by routers as part of their operation. For instance, blind signatures and other zero-knowledge proof schemes can be used to shield sender and receiver data. We can also mitigate the risk of general censorship by allowing for routers to route to each other to create more possible paths through the network (coming in a future release), and by routing communications over TOR.
We’re actively developing and/or investigating these possibilities, and will be iteratively rolling out support for them out over the next 6 months.
Censorship Risk on Messaging
To bootstrap, the Connext team is hosting the messaging infrastructure for the network. We really do not want to do this. It places a large reliance on us to maintain high uptime on the infrastructure and introduces a risk of censorship by the team.
We’re doing this because no reliable decentralized messaging implementation exists yet for web contexts. We’re actively looking into existing attempts like LibP2P and Matrix, and plan to roll our own system if nothing else works.
Contract Upgrades and Registry Control
At the moment, the process for upgrading the protocol and adding new conditional transfer logic to the onchain registry is operated by the Connext team.
Our goal is to work towards Connext being a fully community owned and operated protocol. We’re keeping abreast of the governance research happening in the space, and will keep you all in the loop as we progress in this direction.
📝 What’s next?
Now that Vector is live, we’re refocusing our efforts towards getting adoption with popular L2 applications, supporting more chains/L2s, and making it easy to run routers.
Be sure to follow this blog and our twitter to stay up-to-date!
About Connext
Connext is a crosschain routing network that enables seamless communication between the Ethereum mainnet, L2 systems, and shards.
