Pocket Network has committed to launching a wPOKT product with the aim to bring liquidity from Ethereum ecosystem to and from the POKT ecosystem. The documentation for the initiative can be seen here 21 and here 17. As part of this product, an inter-chain bridge is a key component to maintaining a 1:1 value between the wPOKT Erc20 token and the POKT native token. We propose to build a bridge in this vein, but in a more expansive manner with multiple chains that accurately reflect the current Multi-chain universe reality.
Functionality Overview & Security Advantages
Most bridges in the market today utilize either 'lock & mint' or 'burn & mint' architecture. As these bridges need the ability to manage a token's supply on the destination network, typically the bridging platform will be the one to launch a wrapped version of the token on the destination network. The bridging platform will also maintain administrative and operative control over critical functions of the token contract such as burning and or minting more supply. This approach centralizes control, security, and management of tokens and their economy into the hands of a few dozen bridging platforms. At Ferrum, we are strong proponents of a decentralized world. We feel that these architectural approaches violate the Principle of Single Responsibility (SRP) and introduce the need for trust and centralization in a world that is meant to be trustless through decentralization.
Ferrum Network's architecture for the bridge doesn't rely on having administrative or operative control over the management of the token. Ferrum utilizes a two-way liquidity pool architecture. This means the administrators of the token are able to launch the native asset on any destination network within our ecosystem while maintaining control over the administration and security of the token contract. Additionally, projects and their communities can transfer assets across networks at scale with limited liquidity exposure, unlike other bridges where billions of dollars of liquidity have to be locked up to serve as a backing/peg for the wrapped assets that are minted.
Ferrum relies on chain-level security to ensure the validity of transactions, limit attack vectors, isolate and mitigate the damage from potential exploits, and to ensure decentralization.
For these conditions to be met, the architecture designed required extending the functionality of Pocket Core through additional modules. Namely BridgePool Module and BridgeFee Module as described in the spec.
In accordance with the guidelines by Pocket Network for consensus-breaking changes this update requires 66% of the validator power to be adopted.
Upon approval, Ferrum Integration engineers began work on a path to production for the integration. Per our most recent discussion, We have been advised by the Pocket team and @luyzdeleon in our most recent call (Dated: 30-August-2022) to go through the PIP process for this update. Following the PIP process will allow the community, Pocket Core contributors, and the core engineering team to discuss the architecture and implementation in an open forum, provide feedback and suggest changes, then come to a consensus regarding the upgrade path forward. The following links provide a detailed view of the architecture.
Now, we would like to bring this discussion to a public forum per the recommendation of the Pocket Network team. See the "Add additional context regarding this proposal" section below for more information.
Add additional context regarding this proposal.
Background and Why Were Creating This Issue and PIP
Even though we have previously submitted PEP 11: Bridge to a multi-chain POKT that has been approved. We have been advised by the Pocket team and @luyzdeleon in our most recent call (Dated: 30-August-2022) to go through the PIP process for this update. Following the PIP process will allow the community, Pocket Core contributors, and the core engineering team to discuss the architecture and implementation in an open forum, provide feedback and suggest changes, then come to a consensus regarding the upgrade path forward.
There is a significant effort going into v 1.0 for Pocket Core, however, we believe having a bridge active before that timeline will help the Pocket Network ecosystem and community at large. We are proposing this update for versions < v 1.0. Once we have successfully implemented this update and deployed a successful bridge, we will focus on supporting future versions of POKT's interoperability with enhancements to the bridge and our multi-swap protocols.
Related Efforts
Pocket JS Wallet Client
When we initially engaged there was an indication of a pocket wallet extension or at least extensibility of the wallet through APIs and SDKs being discussed. When it came time for Ferrum to integrate the UI we discovered that the Pocket Wallet plans had not progressed as initially projected. At this point, we took on the task of adding functionality to the Pocket JS Wallet client to enable dApp interaction. We are submitting a PR separately for this purpose. Even though this additional effort was not in the initial scope of the proposal, Ferrum is taking on this initiative as an investment in the long-term collaboration with Pocket Network.
Please explain your change in detail.
PEP 11: Bridge to a multi-chain POKT - Ferrum Network Bridge Module and Fee Distribution Module Functionality
See detailed description in PEP 11: Bridge to a multi-chain POKT
approved
Submitted PIP: Bridge to a multi-chain POKT - Ferrum Network Bridge Module and Fee Distribution Module FunctionalitySummary
Pocket Network has committed to launching a wPOKT product with the aim to bring liquidity from Ethereum ecosystem to and from the POKT ecosystem. The documentation for the initiative can be seen here 21 and here 17. As part of this product, an inter-chain bridge is a key component to maintaining a 1:1 value between the wPOKT Erc20 token and the POKT native token. We propose to build a bridge in this vein, but in a more expansive manner with multiple chains that accurately reflect the current Multi-chain universe reality.
Functionality Overview & Security Advantages
Most bridges in the market today utilize either 'lock & mint' or 'burn & mint' architecture. As these bridges need the ability to manage a token's supply on the destination network, typically the bridging platform will be the one to launch a wrapped version of the token on the destination network. The bridging platform will also maintain administrative and operative control over critical functions of the token contract such as burning and or minting more supply. This approach centralizes control, security, and management of tokens and their economy into the hands of a few dozen bridging platforms. At Ferrum, we are strong proponents of a decentralized world. We feel that these architectural approaches violate the Principle of Single Responsibility (SRP) and introduce the need for trust and centralization in a world that is meant to be trustless through decentralization.
Ferrum Network's architecture for the bridge doesn't rely on having administrative or operative control over the management of the token. Ferrum utilizes a two-way liquidity pool architecture. This means the administrators of the token are able to launch the native asset on any destination network within our ecosystem while maintaining control over the administration and security of the token contract. Additionally, projects and their communities can transfer assets across networks at scale with limited liquidity exposure, unlike other bridges where billions of dollars of liquidity have to be locked up to serve as a backing/peg for the wrapped assets that are minted.
The following articles describe the functionality and security benefits of the Ferrum Bridge in greater detail. The Ferrum Network Cross-Chain Token Bridge Why Bridging with Ferrum is Secure | Nick Odio explains the difference between our bridge vs others A Lesson in Security: Ferrum Cross-Chain Token Bridge
Please provide a justification for your change.
Architecture Proposal
Ferrum relies on chain-level security to ensure the validity of transactions, limit attack vectors, isolate and mitigate the damage from potential exploits, and to ensure decentralization.
For these conditions to be met, the architecture designed required extending the functionality of Pocket Core through additional modules. Namely BridgePool Module and BridgeFee Module as described in the spec.
In accordance with the guidelines by Pocket Network for consensus-breaking changes this update requires 66% of the validator power to be adopted.
As such we are preparing a PIP to accompany the PEP 11: Bridge to a multi-chain POKT
approved
per the guidelines defined in the Pocket Core Contribution Guide.History of Changes & Progress To Date
After building a shell application and vetting out our architecture suggestions, Ferrum presented The Pocket Network Integration Architecture Approach to the Pocket Network team earlier this year.
Upon approval, Ferrum Integration engineers began work on a path to production for the integration. Per our most recent discussion, We have been advised by the Pocket team and @luyzdeleon in our most recent call
(Dated: 30-August-2022)
to go through the PIP process for this update. Following the PIP process will allow the community, Pocket Core contributors, and the core engineering team to discuss the architecture and implementation in an open forum, provide feedback and suggest changes, then come to a consensus regarding the upgrade path forward. The following links provide a detailed view of the architecture.Pocket Network Integration Architecture Approach |:--:| | Flow for Pocket Network <> Ferrum Bridge |
Now, we would like to bring this discussion to a public forum per the recommendation of the Pocket Network team. See the "Add additional context regarding this proposal" section below for more information.
Add additional context regarding this proposal.
Background and Why Were Creating This Issue and PIP
Even though we have previously submitted PEP 11: Bridge to a multi-chain POKT that has been
approved
. We have been advised by the Pocket team and @luyzdeleon in our most recent call(Dated: 30-August-2022)
to go through the PIP process for this update. Following the PIP process will allow the community, Pocket Core contributors, and the core engineering team to discuss the architecture and implementation in an open forum, provide feedback and suggest changes, then come to a consensus regarding the upgrade path forward.There is a significant effort going into
v 1.0
for Pocket Core, however, we believe having a bridge active before that timeline will help the Pocket Network ecosystem and community at large. We are proposing this update for versions< v 1.0
. Once we have successfully implemented this update and deployed a successful bridge, we will focus on supporting future versions of POKT's interoperability with enhancements to the bridge and our multi-swap protocols.Related Efforts
Pocket JS Wallet Client
When we initially engaged there was an indication of a pocket wallet extension or at least extensibility of the wallet through APIs and SDKs being discussed. When it came time for Ferrum to integrate the UI we discovered that the Pocket Wallet plans had not progressed as initially projected. At this point, we took on the task of adding functionality to the Pocket JS Wallet client to enable dApp interaction. We are submitting a PR separately for this purpose. Even though this additional effort was not in the initial scope of the proposal, Ferrum is taking on this initiative as an investment in the long-term collaboration with Pocket Network.
Pocket <> Ferrum Bridge UX / UI (Under review, finalizing UX and branding)