The purpose of this RFP is to seek quotes from established industry leaders in bridge development for a specifically v1 focused wpokt bridge project. Initially I would like to seek a quote from CBridge, but also encourage exploratory work from other suitably qualified vendors.
Almost a year ago, wpokt was an exciting prospect to bring an EVM compatible layer to pokt, and to allow for deeper liquidity in the marketplace via access to decentralized marketplaces. While the inital plan for a Copper LBP was first delayed, then cancelled, there were two bridge development projects in progress:
A Boosty developed bridge to ETH
A Ferrum developed multichain bridge
Since then, the Boosty project was cancelled (due to security concerns around bridge hacks, as I understand it), and the Ferrum project, originally promised to be delivered by Q4 2021 / Q1 2022, has languished in obscurity, with no public updates from the team until a week ago, despite having received the 50% upfront payment, and committing to the project.
Today, Pocket has evolved in countless ways on our journey, and is moving rapidly towards v1, a major overhaul of the network architecture. However, we still have no EVM layer, no DEX access, and per the latest public update from @ArtSabintsev, no clear timeline on delivery.
1. Our lack of access to an EVM compatible layer of pokt has massively delayed development projects requiring such, and prevented deeper liquidity plays which would potentially have helped stabilize token pricing.
As an example, the Pocket Rockets NFT project was counting on wpokt to automate distribution of node farm earnings to NFT holders using wpokt. That project has been live for nearly six months, without the ability to deliver on one of the core offerings promised.
2. Only a native pokt bridge can provide the rapid turnaround time required for many of these use cases.
While derivatives such as tpokt (which I also hold) provide some access to the ETH layer, they’re intrinsically tied to a single noderunning operation, and as such, require a 21 day burn time to redeem native pokt. For the myriad EVM use cases possible with pokt, a rapid turnaround time must be supported. Many bridges are able to move assets in as little as a few minutes, and while this may not be possible with pokt due to the average block time, even an execution time of 1-2 blocks would support a number of the desired outcomes.
3. Security is absolutely critical to this implementation, and we need active and transparent development from an industry leader with a track record that demonstrates their capabilities.
This is not a slight on the work I assume has been done by Ferrum, but rather a specific stance against simply outsourcing additional bridge development work to the (admittedly talented) developers in our community. As we’ve seen from a number of exploits in the last year, including Harmony’s, a project dear to the Pocket community, there’s simply no room here for the risk involved in not using a well established engineering team who are cryptosec experts.
4. Given the radical overhaul of the v1 architecture, it’s likely that existing work will need to be updated to account for those changes.
While the team is working to maintain as much backwards compatibility as possible, the likelihood is high that a bridge architected for v0 is going to need potentially major updates to work optimally with v1. Initiating a separate bridge development project now, which is specifically architected around the v1 structure, will have the advantage of building from the ground up with v1 goals in mind, without the weight of technical debt and legacy implementations.
A multichain bridge, initially supporting $pokt to $wpokt wrapping (and the inverse) on the ETH blockchain, with incrementally added chain support (Poly, BSC, Fantom, etc.)
The bridge will be built with a deep understanding of the v1 architecture, and take into account Pocket’s non-EVM structure without introducing consensus breaking changes.
The bridge will incorporate best in class security practices, and be subject to initial and ongoing security auditing. The development contractor will include a reasonable budget for ongoing security updates and support.
Please comment any necessary technical corrections, inclusions, or context missing from this RFP.