PIP-25: Bridge to a multi-chain POKT - Ferrum Network Bridge Module and Fee Distribution Module Functionality

[FerrumNetwork (Nick Odio)]

Attributes

• Author(s): @FerrumNetwork "Nick Odio, @Taha_Abbasi
• Implementer(s): Ferrum Network
• Category: Protocol Upgrade
• Requires:
• Replaces:
• Fulfills: PEP 11: Bridge to a multi-chain POKT
• GitHub: [CONTRIBUTION PROPOSAL] PEP 11: Bridge to a multi-chain POKT - Ferrum Network Bridge Module and Fee Distribution Module Functionality · Issue #1470 · pokt-network/pocket-core · GitHub

Summary

After the approval of PEP 11: Bridge to a multi-chain POKT Ferrum started working on building a shell application and a detailed architectural solution to enable bridging of POKT across networks.

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.

In accordance with the guidelines by Pocket Network for consensus-breaking changes this update will 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.

Abstract

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

Motivation

Technical and Strategic Mission Alignment

Ferrum Network shares a similar ethos as Pocket Network and is deeply invested in a multi-chain universe. We plan to integrate Pocket Network’s RPC service to support our own applications and infrastructure. Ferrum Network and Pocket Network have been in talks to collaborate throughout the year, and we see this as a natural extension of our mission to help others become more cross-chain compatible today.

Business Use Case and Feasibility

To support the ongoing maintenance and enhancements of the bridge Ferrum charges a fee for each transaction conducted through the bridge. Ferrum recommends sharing this revenue with the Pocket Treasury and Validators and thus adding additional utility to the POKT token through each bridge transaction.

The following revenue share is recommended by Ferrum
Fee per transaction: 2%
Split of the 2% Generated Fee Per Transaction:
40% Pocket Treasury (Liquidity Provider)
20% Validators
40% Ferrum Network

Specification

Background and Why Were Creating This 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.

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.

Node Signing Infrastructure v2.0.0

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.

Architecture Proposal Initiation

Token Transfer Flow Discussion

Keeper Discussion

Pocket Core and Ferrum Node Discussion

Architecture Proposal Approval

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 |

What’s Next

Now, we would like to bring this discussion to a public forum per the recommendation of the Pocket Network team.

Rationale

There is an option to go with a “Lock & Mint” or “Burn & Mint” bridge architecture as serviced by many bridging platforms in the market today. 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.

Dissenting Opinions

Why can’t we build this bridge without updating the core?

Pocket Network is an application specific blockchain and doesn’t have a smart-contract enabled platform for dApps to be built. The only relatively viable solution to build a bridge without updating the core would require a relay verification infrastructure which would move transaction verification off the chain. The lack of smart contract functionality would also mean that the holders of the keys for the Bridge Pools would need to be trusted parties. There were many other issues identified and potential exploit vectors currently unidentified which increased the risk beyond the acceptable tolerance for this integration. The centralized nature of this solution also did not align with Ferrum’s integration approach. Thus we are suggesting a solution that relies entirely on “on-chain” transaction verification and conforms to the ethos of decentralization.

Why is Ferrum charging a fee? Aren’t we already paying them to build the bridge?

The total grant size was $100K, 20K in stables, and $80K in POKT. Ferrum has invested more than the total grant size into this integration just in the first quarter of this year. We continue to invest in this integration because we believe in the growth of Pocket Network, we believe in Pocket Network’s mission, and we want to be active contributors in helping Pocket Network realize that vision. The bridge fee will help us recuperate some of our initial investment and will facilitate ongoing maintenance, updates and enhancements to the bridge when applicable.

Why is Ferrum sharing this update and PIP almost a year after the approval of PEP 11: Bridge to a multi-chain POKT?

Simply put, it’s been an interesting yet engaging process for us. The Ferrum Network and Pocket Network teams were collaborating from the early days of the grant approval. Due to the nature of the grant, we were assigned Valeria Benitez Florez Design & Experience Lead at Pocket Network as a Point of Contact who was helpful in coordinating communications and guiding Ferrum PMs and Engineers. @Valebeflo helped our team navigate the process to contribute to Pocket Network, identify the relevant stakeholders for our integration, she also helped us find stakeholders to answer our questions and provide general support. As an example, Valeria and Pocket POCs brought engineers such as Cristopher Ortega and others to our Discord to review the architecture approaches shared. Under the guidance of the Pocket Team, we continued work. The scope of work had changed significantly as we built the shell app and identified that an update to the core would be needed to meet the security and decentralization requirements of the integration.

We are now actively working with @gabalab as our Point of Contact from the Pocket Network Team. @gabalab has been helpful in organizing calls with Pocket Network CTO and CEO among other stakeholders to facilitate a path forward to deployment of the bridge. While it took time to get to where we are today, it has been a pleasure working with the Pocket Team thus far. In our most recent call (Dated: 30-August-2022) we have been advised by the Pocket team and Pocket Network CTO @luyzdeleon 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.

Viability

Tests

We have implemented test cases in our PR.

Unit tests are written for each function on *_test.go files. Unit tests can be executed by go test ./x/bridgepool/… or go test ./x/bridgepool/…

Integration tests are written on app/tx_bridgefee_test.go and app/tx_bridgepool_test.go and it can be executed by go test ./app/… -run=BridgePool or go test ./app/… -run=BridgeFee

Implementation

Ferrum has already completed the chain side work to add Bridge Module and Fee Module functionality. Now we can discuss, review and provide feedback to the PR, suggest changes, once any suggested changes are implemented, roll the update out through the defined protocol update process.

Audit

Need to identify if Pocket Team will be performing the audit or if a PEP is needed for this.

Copyright

Copyright and related rights waived via CC0.

[msa6867]

Some general comments that may help the ball move forward:

1. not every DAO stakeholder who has a vote is a core dev contributor who will easily be able to navigate through this PIP in order to make a reasonably informed decision on how to vote: I recommend some cleanup to help the pip be readable to as wide an audience as possible

• while pointers to supplementary docs in order to deepdive is fine, the PIP ought to be able to state in plain English sufficiently clearly what the exact nature of the changes are without total reliance on pointers to outside documents
• diagrams with font that is too small to be read are not that helpful. simple diagrams that are readable communicate a whole lot more than fancy layouts that are not readable
• please eliminate unnecessary repetition (e.g., I think one time is sufficient to be told that Luis advised you to submit a PIP); use the saved space to actually give content
• I find that presenting architecture diagrams in a Current/Proposed contrast helps visualize what is changing
• Flesh out the changes in English: eg “Add Bridge Model (approx x LOC) Sits between x & y; requires modification of x & y to integrate with x & y. Provides functionality x. Breaks consensus because of x. Is the preferred architecutral choice because of x. is/is not already coded, etc. Requires x coredev effort to integrate.” etc.

2. Can you please address how this proposal fits in the context of v1 (within the body of the proposal not the comments section). E.g., does the whole effort get scrapped. Do the modules themselves carry over but require separate and new integration in v1. etc.

[Taha_Abbasi]

Hi @msa6867

Excellent feedback. We’ll make those updates today.

CC: @FerrumNetwork

[blockjoe (Joe)]

On the Trust Layer

Thus we are suggesting a solution that relies entirely on “on-chain” transaction verification and conforms to the ethos of decentralization.

I don’t understand how your solution offers significantly more than a trusted relayer. From looking at the repository for the bridge, it doesn’t appear that you’re actually validating the data from the parent EVM chain(s), you’re simply taking the RPC response of the EVM call at face value. There’s a layer of trust in this system that the third party’s RPC availability is always online. Our community has a lot of experience with how often RPC nodes experience downtime, or fall out of sync.

ferrumnet/ferrum-gateway/blob/bab124cd81405b50a2875e19636cb94a43ea5564/bridge-backend/src/TokenBridgeContractClient.ts#L270

From how I understand the rollout, Ferrum will run one of the validator nodes, and Pocket the other. What happens if the Ferrum Validator’s Polygon client falls behind sync from the Pocket Validator’s client? Every node runner in this community would tell you how easy it is for something like this to happen. I see there’s a configurable variable for how far back to look for swaps. It looks like 990 blocks back for mumbai, which would mean only a 30 minute window that if downtime isn’t caught, there needs to be trusted coordination between validators to restore any missed transactions due to downtime.

In a large network of permissionless validators, I don’t think this is a problem, but validating on the Ferrum network is a permissioned ecosystem. This means that until there is sufficient scale, this model risks becoming a trusted decentralized system. While I understand that Mint & Locks have the issue of that single point of failure, I don’t think Ferrum’s network is currently at a scale where we can have faith that an outage incident from a validator isn’t going to cause major disruption.

On the Pocket Core Performance Impact

While I understand the risk that comes from centralized multi-sig bridges, and I think the Ferrum team are on to something with having limited liquidity on the bridge at any given moment, I have a hard time swallowing that the protocol (which we’re already pushing to its limits), is ready for us to force in so much new functionality to essentially hard code in a solidity smart contract into our consensus layer.

Pocket is a hyper focused application specific blockchain that we’re already pushing to its limits. Has the Ferrum team done any analysis on what kind of impact that these changes will have to the Protocol in production? This was a significant motivating factor from the “don’t touch Pocket Core” requirements that you still have outlined in the “Must Haves” section.

The PR submitted includes 13 new message types to Pocket Core. Pocket Core only had 12 message types before this. While this likely isn’t going to be representative of the load to the network, it is representative that this is a lot of new added complexity, with its only functionality going to be emulating a smart contract that’s only designed and utilized within the Ferrum ecosystem.

What Would Be Helpful to See

1. Sufficient evidence that the Ferrum network has enough validators to handle a prolonged outage of a Validator’s RPC client.
2. Some estimates of the impact that this will have to the following when deployed to production:
   i. State Size (this effects Pocket’s ability to gossip the information across the network it needs for consensus)
   ii. RAM Usage (our node runners already have high memory demands for running on the network)

[Jinx (Chris Jenkins)]

@FerrumNetwork

In accordance with the guidelines by Pocket Network for consensus-breaking changes this update will requires 66% of the validator power to be adopted.

Despite the long lead time with complete lack of community updates, and what appear to be multi-month gaps in repo commits relevant to the pokt bridge, I have been holding out hope that this project could be brought home in a timely fashion. However, the single biggest thing that continues to stand out to me is a lack of consistency, even in things as simple as describing what will be required to implement the bridge.

Is this going to be a consensus breaking change or not?

Having spent twenty years in leading software engineering teams (and as a developer myself), I very much understand that unforeseen difficulties can arise, especially when the complete scope of the project is not well understood by the development team, which seems to have been the case here. Inadequate initial architecture aside, the response of the development team at that moment of discovery is often the make or break factor which helps determine the project’s success.

In this case, it appears that upon discovering that difficulty, the Ferrum team perhaps made an initial effort at notifying the Pocket core team, which was understaffed at the time, and then…did nothing? For months?

In previous communication here, the Ferrum team advised that they had been in “constant communication” with the Pocket team through out all this time, and that failing to update the DAO which is funding this project was “simply an oversight”.

There was no oversight in proposing to the DAO.

There was no oversight in accepting the initial 50% payment from the DAO.

There’s simply been a year of intermittent activity on a series of repos which suddenly ramped up in the last two months as it became clear the community was reaching a breaking point around this project. Hell, even the stubbed out demo should have been ready on the first call last week, and appears to me to have been rapidly developed in the last week or so.

Which brings us back around to where things stand now, on what appears to ACTUALLY require a consensus breaking change, contrary to what Nick advised literally last week.

To my knowledge, Pocket has exactly ONE full time engineer focused on supporting the v0 track, as all resources are focused on the v1 deliverables. All v0 deliverables require pulling engineering resources from v1 to implement, which potentially delays the launch of v1, a critical step forward in meeting the promise of truly decentralized architecture. Implementing a consensus breaking change will require more than simply merging “side car modules” as was intimated by the Ferrum team in their first call with the community.

The inconsistent messaging, additional labor requirements, additional timeline, and questionable underlying architecture (as outlined in @blockjoe and others’ comments) are all adding up to be a non-starter for me. While I’ve been excited about the potential of wpokt (for all of the reasons outlined in my RFP-11: A Bridge To The Future post), the risk to reward ratio of continuing down the current path has flipped in favor of waiting to see what sort of native on-chain mechanisms (such as an IBC integration) can be implemented in v1.

I am casting a vote of no-confidence in this project as it stands.

[Cryptocorn]

I’m deeply concerned with who the Ferrum team are and who is actually producing this work.

We seem to have a strategy officer as acting CEO/CTO and a Project Manager running an external team that seems to have only started working again once the community moved to cut off funding.

While Pocket Network could have been a little more responsive, that doesn’t discount or obfuscate the lack of work and communication by Ferrum. Seems like they are trying to blindside the community with technical talk while posting some downloaded architecture diagrams and trying to shift blame to Pocket Team.

Ferrum haven’t answered my questions in the past and it looks like they whipped together a basic demo to receive more funding. They’ve lost my support and I don’t think they should be trusted with such core infrastructure. I will be voting no on this and looking for other options.

[Sandy410 (Sandy Gibbs)]

Can you name your:
CEO:
CTO:
COO:

Are they full time employees of Ferrum or out sourced?

[Harvey007 (Harvey)]

Yeah, this stinks of being a shady two man operation (Taha + Nick) who outsources all the work to Pakistan. All the tech leads named on the call work for a 3rd party BPO, not Ferrum.

[Zack-Ackerman (zackie)]

Wow, these guys are dodgy, just trying to milk the DAO for more money while demoing basic stuff.

If the community hasn’t seen it, Taha looks like a known swindler:

BEWARE OF TAHA ABBASI

[Taha_Abbasi]

@msa6867 a more detailed response regarding your suggestions

1. not every DAO stakeholder who has a vote is a core dev contributor who will easily be able to navigate through this PIP in order to make a reasonably informed decision on how to vote: I recommend some cleanup to help the pip be readable to as wide an audience as possible

We’re going to update the PIP after updating all related artifacts and incorporating suggestions provided by the community and the team. I expect some updates to be done today and tomorrow, while others by Wednesday as they require a bit more planning regarding the changes requested.

• while pointers to supplementary docs in order to deep-dive is fine, the PIP ought to be able to state in plain English sufficiently clearly what the exact nature of the changes are without total reliance on pointers to outside documents

We’ll update the PIP to include architecture detail and information shared in referenced docs to provide more clarity. We’ll still include the linked references if someone wants to dive into greater detail.

• please eliminate unnecessary repetition (e.g., I think one time is sufficient to be told that Luis advised you to submit a PIP); use the saved space to actually give content

Good point we’ll remove the repetition. It was stated in a different context to describe how we ended up here and the importance of a discussion in a public forum. We’ve already received tremendous feedback in less than 48 hours. This will help us make the necessary adjustments and refine the PIP until it’s at a feasible point for the DAO to review.

• I find that presenting architecture diagrams in a Current/Proposed contrast helps visualize what is changing

This is a great suggestions and we’re updating the diagrams to display a comparison of current and updated arch approaches.

Flesh out the changes in English: eg “Add Bridge Model (approx x LOC) Sits between x & y; requires modification of x & y to integrate with x & y. Provides functionality x. Breaks consensus because of x. Is the preferred architecutral choice because of x. is/is not already coded, etc. Requires x coredev effort to integrate.” etc

Another great suggestion and we’re incorporating this along with the diagram updates.

2. Can you please address how this proposal fits in the context of v1 (within the body of the proposal not the comments section). E.g., does the whole effort get scrapped. Do the modules themselves carry over but require separate and new integration in v1. etc.

V1 is an entirely different implementation based on what is known currently we’ll need to make updates on V1 but the updated implementation will be able to plugin to the already implemented cross-chain infrastructure. More detail on this will be provided and included in the PIP.

[Taha_Abbasi]

@blockjoe thanks for your comments. I’m sharing a few items below that may help clarify a few points, and I’m taking some of your suggestions to our team to review.

On the Trust Layer

Thus we are suggesting a solution that relies entirely on “on-chain” transaction verification and conforms to the ethos of decentralization.

I don’t understand how your solution offers significantly more than a trusted relayer. From looking at the repository for the bridge, it doesn’t appear that you’re actually validating the data from the parent EVM chain(s), you’re simply taking the RPC response of the EVM call at face value. There’s a layer of trust in this system that the third party’s RPC availability is always online. Our community has a lot of experience with how often RPC nodes experience downtime, or fall out of sync.

ferrum-gateway/TokenBridgeContractClient.ts at bab124cd81405b50a2875e19636cb94a43ea5564 · ferrumnet/ferrum-gateway · GitHub

When I mentioned the following in the PIP

Pocket Network is an application specific blockchain and doesn’t have a smart-contract enabled platform for dApps to be built. The only relatively viable solution to build a bridge without updating the core would require a relay verification infrastructure which would move transaction verification off the chain. The lack of smart contract functionality would also mean that the holders of the keys for the Bridge Pools would need to be trusted parties. There were many other issues identified and potential exploit vectors currently unidentified which increased the risk beyond the acceptable tolerance for this integration. The centralized nature of this solution also did not align with Ferrum’s integration approach. Thus we are suggesting a solution that relies entirely on “on-chain” transaction verification and conforms to the ethos of decentralization.

I was referring to the approach where Ferrum nodes monitor transfer to an address, this doesn’t require changes to the core. The initial approach was going to rely on Ferrum bridge node infra monitoring transactions and transfers to an address on Pocket Network, this address was to serve as a bridgePool and the Ferrum Noda Infra would go through a set of verification procedures before releasing assets on the desired EVM network. Vice Versa coming from an EVM Network to Pocket Network Ferrum Node Infra would monitor our bridgePool contracts as expected and then on the Pocket Side it would need to release those assets from the bridgePool to the user’s wallet. This approach centralizes too much responsibility towards the bridge node infra. It also limits the required exploit vector to drain liquidity to Ferrum’s Bridge Infra. As compared to the approach, we’ve worked on where liquidity extraction would require an attack on the bridgePool Module as well as the bridge node infrastructure.

Regarding the referenced code you mentioned here:

ferrumnet/ferrum-gateway/blob/bab124cd81405b50a2875e19636cb94a43ea5564/bridge-backend/src/TokenBridgeContractClient.ts#L270

You are looking at only the bridge transactional implementation side of things, swaps, add liquidity, remove liquidity, and withdrawals.

The verification and authentication of these withdrawals is not done here. You need to look at the Generator, Validator, and Master nodes here:

ferrum-gateway/bridge-backend/src/node at main · ferrumnet/ferrum-gateway

ferrum-gateway/bridge-backend/src/node/docs at main · ferrumnet/ferrum-gateway

From how I understand the rollout, Ferrum will run one of the validator nodes, and Pocket the other. What happens if the Ferrum Validator’s Polygon client falls behind sync from the Pocket Validator’s client? Every node runner in this community would tell you how easy it is for something like this to happen. I see there’s a configurable variable for how far back to look for swaps. It looks like 990 blocks back for mumbai, which would mean only a 30 minute window that if downtime isn’t caught, there needs to be trusted coordination between validators to restore any missed transactions due to downtime.

We now log the transaction hash generated at the initiation of a swap. We are able to query those transactions and re-run validation to re-sync when this issue arises. This has happened multiple times with BSC as well. We’ve been able to mitigate the issue by utilizing the process and tooling for re-syncing in these situations.

In a large network of permissionless validators, I don’t think this is a problem, but validating on the Ferrum network is a permissioned ecosystem. This means that until there is sufficient scale, this model risks becoming a trusted decentralized system . While I understand that Mint & Locks have the issue of that single point of failure, I don’t think Ferrum’s network is currently at a scale where we can have faith that an outage incident from a validator isn’t going to cause major disruption.

The above response should address this concern. If a validator is out of sync due to issues with RPC nodes or any other issue, we are able to initiate a resync process.

Pocket is a hyper focused application specific blockchain that we’re already pushing to its limits. Has the Ferrum team done any analysis on what kind of impact that these changes will have to the Protocol in production?

We have run the changes by running the updated core ourselves, but I see value here in doing a set of stress and load tests at scale. I’ll review this with our team.

The PR submitted includes 13 new message types to Pocket Core. Pocket Core only had 12 message types before this. While this likely isn’t going to be representative of the load to the network, it is representative that this is a lot of new added complexity, with its only functionality going to be emulating a smart contract that’s only designed and utilized within the Ferrum ecosystem.

I look at this a bit differently, it goes back to why we are adding this functionality. The goal is not to integrate with the Ferrum Ecosystem, rather enabling the interoperability of POKT with over a dozen EVM and a few more non-EVM compatible networks. In doing so, we hope to bring POKT access to a community of millions on these networks and facilitate the means for significant TVL to flow into the network.

What Would Be Helpful to See

1. Sufficient evidence that the Ferrum network has enough validators to handle a prolonged outage of a Validator’s RPC client.

We will provide arch diagram and code overview for this so the community can review and ask any questions.

What Would Be Helpful to See

2. Some estimates of the impact that this will have to the following when deployed to production:
   i. State Size (this effects Pocket’s ability to gossip the information across the network it needs for consensus)
   ii. RAM Usage (our node runners already have high memory demands for running on the network)

I mentioned this in one area above, I totally agree with this, and we’ll work on a test plan to show the impact.

[Taha_Abbasi]

Hi @Jinx

Thanks for your feedback.

Let me address the issue of consensus breaking or not. What @FerrumNetwork (Nick Odio) mentioned in the Telegram message referenced in your picture was referring to the fact that the following areas of the consensus protocol will not be impacted:

Reference

Pocket contribution guide defines consensus breaking changes as follows:

Consensus-breaking changes

A consensus-breaking change means a change that would require 66% of the Validator Power in the network to be adopted. Furthermore these changes need to be voted in and approved by the DAO. To propose a consensus-breaking change please follow the Pocket Improvement Proposal documentation found here.

Your key question was:

Is this going to be a consensus breaking change or not?

The nature of the update will actually require an update to the core as it is proposed and implemented. Hence, according to the definition described in the Pocket Contribution guide, it will in fact be a consensus-breaking change.

To be clear Nick was sharing information he had been provided so this is not on him, we need to improve in this area as you can see we are making an effort to improve direct communication with the community.

In this case, it appears that upon discovering that difficulty, the Ferrum team perhaps made an initial effort at notifying the Pocket core team, which was understaffed at the time, and then…did nothing? For months?

There’s simply been a year of intermittent activity on a series of repos which suddenly ramped up in the last two months

This is not the case. When we discovered the adjustment in scope, we had to make updates both on the Ferrum Node Infrastructure side and client side in addition to changes to core and wallet client.

Please review:
https://ferrumnetwork.atlassian.net/wiki/spaces/FN/blog/2021/12/23/329941007/Connecting+EVM+to+the+Rest+of+the+World+Phase+1
https://ferrumnetwork.atlassian.net/wiki/spaces/FN/blog/2022/02/08/334102548/POKT+wPOKT+and+Ferrum+Network+Token+Bridge+Integration+Update

GitHub - ferrumnet/ferrum-gateway: Ferrum Gateway monorepo

GitHub - ferrumnet/pocket-core: Official implementation of the Pocket Network...

GitHub - ferrumnet/pocket-core-func-tests: A repository outlining all the...

Also review forked repos by our engineers or you can review the PRs when they are created.

While I’ve been excited about the potential of wpokt (for all of the reasons outlined in my RFP-11: A Bridge To The Future post), the risk to reward ratio of continuing down the current path has flipped in favor of waiting to see what sort of native on-chain mechanisms (such as an IBC integration) can be implemented in v1.

Per my latest conversation with the Pocket Network team, while there isn’t a defined timeline around v1, it’s currently scheduled to start roll-out around Q3/Q4 of 2023. This could be delayed as is the case with any complex undertaking.

Given that Ferrum will take on the technical debt and burden for the changes requested, regression testing, performance impact reports, and Alpha testing. I don’t see how it has more than a low-to-moderate impact to the network. I’m sure there will be updates between now and v1 and this update can be included along with it. We will make sure to incorporate and satisfy the community, PNI and DAOs concerns before the PR is actually considered for merge and rollout to BETA.

Not launching this bridge means:

1. Giving up on nearly a years worth of effort
2. Delaying POKT / wPOKT interoperability for potentially another 24 months+

---

Hi @Cryptocorn

Thanks for your feedback. I’ll share some responses to your questions. I see that others have also raised a few questions regarding our team and staffing. I’ll share responses to all those posts in this response.

We seem to have a strategy officer as acting CEO/CTO

I believe you are referring to me here. I started off as an investor in the organization, joined the GC, and eventually came on board full-time as the Chief Strategy Officer at Ferrum. I am an engineer by background and have served organizations as Chief Software Architect and CTO for a good part of the decade. I have taken over CTO responsibilities in the last quarter.

Project Manager running an external team
I believe you are referring to the staffing agency we use. All Ferrum team members are full-time employees. Due to our incorporation jurisdiction, and local regulations, benefits administration among other things we work through staffing agencies where we cannot directly employ team members. Regardless of the entity that manages payroll, benefits globally, 95%+ of the Ferrum team are full-time team members.

Ferrum haven’t answered my questions in the past

@Cryptocorn please post your questions here and I’ll answer them

Can you name your: (@Sandy410 @Joe018 )
CEO: Naiem Yeganeh
CTO/CSO: Taha Abbasi
COO: Ian Friend
CGO: Nick Odio

Are they full-time employees of Ferrum or outsourced?

All of the team members mentioned above, along with the entire dev team is full-time Ferrum team members.

Yeah, this stinks of being a shady two man operation (Taha + Nick) who outsources all the work to Pakistan. All the tech leads named on the call work for a 3rd party BPO, not Ferrum.

@Harvey007 guys, can we keep this civil and focused on actual feedback/questions about the project and proposed changes? There really isn’t a need to be uncivil.

Wow, these guys are dodgy, just trying to milk the DAO for more money while demoing basic stuff.

If the community hasn’t seen it, Taha looks like a known swindler:

@Zack-Ackerman Really?

1. This PIP is not asking for more funds. It’s just a request for feedback and suggested changes so Ferrum can continue to invest in this integration and in the success of Pocket Network.
2. This occurred when I learned that my name and credentials were being used by that company’s founder to raise funds from investors and the money raised was being embezzled. Employees weren’t being paid, bills weren’t being paid, etc. I brought up the issue internally and requested the practices to stop.

Long story short, I was let go as I didn’t get with the program and this followed along with a cease and desist to try to keep me quiet. You can review the details of the lawsuit here.

Here is some more info that might help.

The CEO of Tryp deployed a defamation campaign to try to stop me from reporting him to the authorities. This is explained in the lawsuit. The guy was embezzling money and not paying employees.

The content of these blogs is completely fabricated and immensely defamatory.

I asked my colleagues who “supposedly” wrote those blogs for comment, each one of them completely denied these claims. They were appalled at the content being shared and how I was being misrepresented.

I asked my colleagues for their video testimonials.

1. CEO of Evelar

2. CRO of Evelar

3. Board Member and Co-Founder at SimuStream

My request for testimony

https://www.videoask.com/fv0eoanhu

Their responses:

https://www.videoask.com/rjkkxu9jhihon43lnt3hlopuhg39j2jh864s0a9l

Important Note and Clarification

I’m excited to review the feedback shared here with our team and come back with updates to the PIP…

I want to clarify one thing, this is not a request for additional funds. Just for feedback and to answer questions and make adjustments in a public forum. Also, there were mentions of Ferrum trying to put the blame on the Pocket team. We are in no way trying to put any blame on Pocket Network team or point fingers. In fact, we are thankful for the support they have provided thus far.

We truly appreciate the accountability and thoughtfulness the community is bringing to the table. We’re committed to getting this done correctly and won’t give up. We’ve got some homework, we’ll get right to it.

A note, in the US Monday is a holiday, so some of our responses might not come until Tuesday / Wednesday.

[FerrumNetwork (Nick Odio)]

Taha seems to have already addressed most of the concerns outlined here. One thing I would like to point out is that the original PEP was written in a way that gives Ferrum a pegged price of POKT at the time of the PEPs approval. At that time POKT was at $0.34; a number that has been reduced drastically to $0.125 currently. The final $50k worth of POKT that we would receive after completion is now worth about $18k at the time of writing. So when folks talk about us trying to ‘receive more funding,’ they’re overlooking the fact that we’ve already spent far more than we’ve received or will receive. Sure the transaction fees on the bridge should offset that but that requires a working product and will also bring revenue to the Treasury.

Guys, its in our best interest to get a secure and properly functioning product to market as quickly as possible. I have to say, all of this talk about questioning our integrity or intentions seems to be driven more so by emotions and market conditions. We all have a common goal here. A great deal of effort has been put forth so far and we’re extremely close. Unless you want to wait until V1 (could be over a year) or hire someone to create an offchain solution (outside of the decentralized ethos of Pocket), someone would have to come in and redo all the work that we’ve already done. For 18k worth of POKT, are we really weighing our options rationally? How much more is someone else going to require to build a similar solution from scratch? Will that solution benefit the Treasury and add more utility to POKT? It would be such a shame to scrap this at such a late stage. Let’s work together to get it across the finish line.

[steve (Steve Tingiris)]

@Taha_Abbasi, I’ve honestly not been paying close attention to PIP-25. However, as trusted community members began expressing their concerns, that got my attention.

I’ve led the development of numerous enterprise-scale software projects over multiple decades. In general, they never go exactly as planned and it’s common to get disillusioned at points throughout the project. So, I fully expected to dive into this only to see just another project that turned out to be more challenging than expected - like every other large-scale project.

For the most part, that probably would have been my assessment - until I read the following:

@Taha_Abbasi

i. I can advise my legal team to add you to the lawsuit and add you to the list of personally liable individuals for damages incurred as a result of the defamation.

When legal action is used to threaten someone who is posting publicly available links (to content created by someone else) - that raises a BIG flag from my perspective. But the following really cemeted my viewpoint on next steps for this project:

@Taha_Abbasi

ii. You are exposing this Forum, potentially the moderators as well as PNI and the DAO in essence. It’s not a good path to go down. You can review the details of the lawsuit here if you’d like to understand the magnitude of liability exposure. It’s been roughly 2 hours since you have posted this. Each view since then and each link click adds to the liability.

The use of threats as an attempt to stop people from sharing publiclly available information - in an open forum - should not be tolerated in my opinion. While I probably would have ignored the content in the blog post that was shared - after reading your threats here - I’d seriously advise every community member and the leadership team to pause and reflect on why you might feel the need to make such threats.

The reasons you provide for continuing on are:

@Taha_Abbasi

• Giving up on nearly a years worth of effort
• Delaying POKT / wPOKT interoperability for potentially another 24 months+

In my opinion, we should cut our losses - NOW. Neither of your reasons for moving forward is worth the risk of exposing even a single member of our community to your threats.

[Taha_Abbasi]

@steve i shared the above per the advice of my legal team. There’s active discussion in the community TG currently answering some questions.

I might remove the wording Lawyers sometimes aren’t the best at providing contextual advice. To clarify this is not a threat, it’s a request to stop circulating the defamatory content. The court filings can be shared. Again this is advice from the legal team.

[steve (Steve Tingiris)]

@Taha_Abbasi The fact that you feel the need to have legal counsel provide wording for a post from you, in an open online forum, concerns me even further.

[Taha_Abbasi]

When it comes to a lawsuit and content related to that filing, I would think it makes sense to get the advice of the people we’re paying to deal with it.

Regardless, I’ll update the wording and redirect focus on the technical side of the proposal.

[steve (Steve Tingiris)]

Sounds like you might be paying the wrong people. But regardless, for me, the concern stands.

[msa6867]

@FerrumNetwork

The following revenue share is recommended by Ferrum
Fee per transaction: 2%
Split of the 2% Generated Fee Per Transaction:
40% Pocket Treasury (Liquidity Provider)
20% Validators
40% Ferrum Network

This is a HUGE red flag for me and is a complete nonstarter. Creating a revenue stream for validators that is decoupled from and indeed could exceed the revenue stream for validating Dapp RPC transactions creates a complete misalignment between the interests of validators and the best-interest of the Pocket Network. I was fine with the original 50/50 proposed split between Ferrum and DAO. Why the recent update to giving a 20% carveout to validators. Seems like a vote-pandering ploy to me. And I’m curious just how much architecture bloat was added just for the purpose of creating this carveout? Furthermore, the Pocket DAO constitution expressly forbids this type of arrangement. Section 4.25 states:

• As the actors responsible for transaction finalization in Pocket Core, Validator Nodes have the power to overthrow the government apparatus of Pocket Network (outlined as the above Legislature, Executive, and Judiciary functions). They are trusted to represent the citizenry (Users) of Pocket Network because their Block Reward is tied directly to the number of relays being processed for developers (i.e. User usage). The Council must never approve Protocol Upgrades that would decouple this incentive alignment.

In order for this PIP to proceed, I strongly advise to revert the proposed revenue sharing to the original 50/50 and revise all architecture diagrams, modules etc, to reflect that this carveout is no longer on the table.

Aside from my “vote pandering” comment, there must be some reason you are suggesting the carveout… what is it that the validator must do to enable the bridge that is unique or different than any other random message/transaction that it must validate. Something like, “the validator is required to scan the header of all messages and if it is a match for a ferrum bridge message it must open the package and take detailed action that is not taken for other message types”… I’m just making this up because I don’t know enough about how the process works or the right lingo to use… if an existing written document is sufficiently clear so as to answer my question, then a pointer is fine, though a pointer + executive summary would be even better.

[solstar]

In the general very polite context of the post those statements were made in I didn’t read it as a threat
but rather as asking to take it down asap and explaining the legal reasons for not spreading defamatory information. I can only imagine such stuff has caused a great deal of pain and anger to those accused…

Some of the posts here have a really hostile mood, I don’t entirely get why. Obv Ferrum has recently been allocating more resources into finally finishing the bridge and are seeking feedback from the community.
And they are giving a recommendation for fees and it is perceived as a “red flag”? I mean, worst case it was just a recommendation.
Luckily also some constructive posts and in my opinion a lot of effort to respond to everybody’s questions and suggestions.