RFP-11: A Bridge To The Future

Ideas
1

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.

History

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.

image

Concerns

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.

The Proposal Requirements

  • 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.

Calls For Improvement

Please comment any necessary technical corrections, inclusions, or context missing from this RFP.

5 Likes
2

Hi Pocket Network Community,

This is Taha Abbasi, I serve as the CSO at Ferrum Network leading our engineering teams and business strategy as well. I’m writing this update with Nick Odio our EVP of Partnerships and Growth on behalf of the Ferrum Network team.

As supporters of interoperability and a multichain world, we are always in favor of more ways to allow value and data interoperability. So we commend this proposal. We would like to take this opportunity to share some updates that may help shed some light on the progress of the Pocket Network bridge that Ferrum has been building.

Communication

Let's start by addressing a core issue which is communication. Communication issues are generally at the core of the most frustrating experiences. In this case, we believe the lack of communication and updates shared with the Pocket Community has amplified concerns and left the community looking for answers that no one seems to be answering. We will take full responsibility for this from Ferrum Network's side. We have been in regular weekly communication with the Pocket Network team, with weekly calls, progress updates, and tasks both from technical and operational standpoints.

We are strong believers, and supporters of the mission Pocket Network is set out to do, which is why our first Pocket Network payment was staked to run nodes on the network. In that same essence, we understand from the conversations with the stakeholders on the Pocket Network team that there is a prioritization regarding marketing and communication from Pocket Network's side. Currently, there is a major update coming to the Pocket Core, and all communication, updates as well as initiatives are directed towards that effort. This is something we are also very excited about as supporters of Pocket Network. However, we feel that this is an area we can step up and support the Pocket Network team by directly posting updates in the forum and chats of the Pocket Community rather than communicating in private groups.

Progress

The Bridge and Pocket Core

After almost a year of effort, we are now submitting our PR to the core for all the updates finalized and demo'ed to the Pocket Network stakeholders last week. The demo included a functioning Bridge Pool Module as well as a Fee Distributor Module with the ability to Add Liquidity, Remove Liquidity, Initiate Swaps, Withdrawals, Setup mapping of POKT to ERC20 versions on Polygon, BSC, Ethereum, and any other network POKT decides to go live on in the future. This means that all the module work related to core functionality is now complete.

In the PR, we'll include all the detail regarding the architectural approach, the reasons for choosing to update and extend the core vs off-chain solutions, and all of the code for the update. Per the guidance of the Pocket Network team, after the PR is created it will be sent for DAO approval before merging.

Security Concerns and Scope Adjustment

When we initially engaged with Pocket Network on the integration the scope did not include updating the core simply because this would have been a much larger undertaking than integrating with Ferrum's node Infrastructure and just launching a dApp to take care of the front-end. However, upon a detailed review of the architecture, we identified security concerns with the original approach which introduced an element of centralization and would have taken elements of the core integration off-chain. These were unacceptable compromises in our view thus we adjusted the scope to keep all core elements of the integration on-chain by building modules that extend the Pocket Core. This is something we wish was communicated to the community months ago as it significantly increased the scope of work which impacted our timelines. Nevertheless, we will rectify the communication issue starting today and work to turn this shortcoming into our strength over the coming days and weeks.

Pocket Wallet JS Client

Another element that wasn't in the initial scope was extending and upgrading the Pocket JS Wallet client. This is required to give users the ability to interact with a dApp through a user interface and conduct swap / withdraw transactions. Our understanding at the beginning of the engagement was that there are teams and community initiatives working on enabling this functionality for the Pocket Wallet. When it came time to integrate the Pocket Wallet into the dApp UI, we learned that this was not the case. At this time we had to determine our options which were limited.
  1. Wait and hope someone updates the Pocket Wallet to enable this functionality as it wasn’t in scope
  2. Adjust the scope again and build the required functionality for the Pocket Wallet ourselves

Once again, being strong supporters and investors in the Pocket Ecosystem, we took on the task of updating the wallet. The exciting thing about this undertaking is the fact that once we complete the update to the wallet, other developers can utilize what we’ve built to enable dApp interaction through a UI using the Pocket Wallet. This can include staking, unstaking, and even interactions with a DEX could be possible with some additional modules to the core.

We are giving a demo for the Pocket Wallet update to the team along with its interaction with the bridge UI the week of 29th August. This will be an end-to-end demo of swaps being conducted from Pocket Network to Polygon and back.

Operational Items

In order to securely set up management and ownership of the POKT token on EVM compatible networks, we requested 9 signatories to be placed in a multisig governance safe for all critical functions of the token contract such as updating supply, ownership-related functions, admin functions, and more. This has taken some time, and we are still waiting to receive an update from a few signatories identified by the Pocket team per their last update. This process has been pending for about 2 months so we're hoping to finalize it as it will block launching the token on Polygon

The Finish Line

After nearly a year of effort, we are now preparing for an Alpha Launch. Giving up on this integration now would mean walking away from all the work, time, and resources that have gone into making it a secure and lasting solution for POKT’s interoperability.

I’d like to focus on correcting the communication issue which includes sharing our Jira board, holding AMA’s, and sharing the entire plan along with weekly updates and regular communication as we prepare for Alpha Launch.

Ferrum is and always will be a strong backer of Pocket Network, which is why we are not interested in a transactional relationship. We believe this is the beginning of many more opportunities to collaborate with Pocket Network. As such, we are happy to do whatever it takes to support the team and the community to ensure the success of Pocket Network.

CC: @FerrumNetwork

4 Likes
3

Thank you for updating the community, this is the most helpful.

Looking forward to weekly updates and other communications as we are inching towards the launch.

5 Likes
4

Hey @Jinx,

I wanted to provide some additional thoughts about this solely from the V1 point of view.

The roadmap we have for V1 doesn’t have a bridge or any interoperability on it, but I personally don’t see a world where it’s not something we pursue after v1 mainnet launch.

Whether we go with a bridge-based approach liked Ferrum or a more general purpose interoperability solution like Axelar, Nomad or IBC is still TBD but I don’t think that adopting one option prevents another.

Regarding timelines, I think designing or discussing this is premature until we are at or close to mainnet. We need to stay laser-focused right now.

Once v1 mainnet is launched, the landscape for interoperability protocols and bridges will likely look very different than today, and we can revisit the best solution then. I believe having a pocket native v1 codebase will significantly reduce the scope and difficulty of this project relative to what we have seen in v0.

I’m also hoping that we’ll be able to bounty out certain parts of this to the community in a multi-stage process:

  1. RFP for various bridge or interoperability solutions
  2. Review different designs (sequence diagrams, interfaces, etc.…)
  3. Evaluate the level of complexity and risk of each one
  4. Implement the solution
  5. QA the solution
  6. Manage deployment

The core team will be involved and need to provide guidance at each step along the way, but the great part is that we don’t necessarily need to have a single owner the whole way through and can have parallel efforts supporting different protocols.

I realize this answer doesn’t provide any definitive action items but just wanted to let you know that it is something we are thinking about.

Olshansky

4 Likes
5

I’m hearing that IBC is a viable path in v1, which I’d be excited about. Thanks for weighing in here.

1 Like