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

Proposals Improvements
6

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.

3 Likes
7

Can you name your:
CEO:
CTO:
COO:

Are they full time employees of Ferrum or out sourced?

2 Likes
8

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.

9

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:

11

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

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

12

@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:

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:

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

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

13

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:

image
image971×1451 184 KB

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

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.

1 Like
14

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.

1 Like
15

@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:

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:

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:

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.

1 Like
16

@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 :man_shrugging:t4: 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.

17

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

1 Like
18

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.

19

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

20

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.

2 Likes
21

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.

2 Likes
22

yes the 40/40/20 is a red flag. And it is no mere “recommendation”. The architecture has been shifted from what was originally proposed in order to accommodate this feature. As soon as they revise the draft to revert back to 50/50 and scrub this feature from the architecture then this red flag gets removed. Until then, it remains. An by “reverting” etc. I do not mean “recommend 50/50/0 as the initial setting”… while leaving all the hooks in place for the validators to decide amongst themselves at some later date to vote themselves a 20% allocation pay-raise with the rest of the network powerless to stop them from doing so. From the perspective of ensuring that validator interests are and remain aligned to best interests of Pocket, I want it completely out of the architecture.

In the meantime, I am awaiting feedback from Ferrum as to what diversion from ordinary duty the validators are being called upon to perform in order to enable the bridge that led to the thought of allocating reward to the validators in the first place. I ask, because removing the validator compensation then places validators in the opposite conundrum - being asked to do extra work outside of normal duties with no compensation for the extra work performed.

This is a crucial point to get to the bottom of because by definition, whatever the “this” is, is going to be one of the main places to discern where this proposal breaking consensus, when Ferrum is insisting it does not. How in the heck do you say that modifying the fundamental reward structure of Pocket can be accomplished on chain without breaking consensus. It makes no sense to me. Off chain compensation (Ferrum collects fees and once a day sends to participants wallets) could possibly avert breaking consensus but what about the extra work the validators are being asked to perform).

If it does not break consensus, then there is zero need to tie the architecture to involve POKT validators. The natural solution to making a bridge decentralized and not reliant on trusted parties is to define a completely separate entity, lets call it a “Ferrum validator” (not to be confused with a POKT validator). And then provide a reward structure and put out to various discord channels etc. With the right reward structure and confidence of volume materializing, I bet Ferrum could get a thousand Ferrum validators spun up in a heartbeat. Why enmesh this functionality with a POKT validator? A POKT-ETH bridge would naturally be validated by a PoS “Ferrum Validator” staked w both ETH and POKT. Seems like a win-win. POKT validators are out of the picture and Ferrum has a plug-and-play architecture to drop on any other bridge they build

Last, if they go this rout I can foresee 60/40 so that ferrum can carveout from their 60 whatever they need to create an incentive reward structure for this separate entity type

23

@msa6867 I’ll answer the other points in a bit. But regarding fees, these are configurable through a function call. It’s not set in stone we’re looking for feedback.

24

To be clear, I did go through those reference links, which is where I got the impression from to begin with:

image
image803×208 10.8 KB

image
image819×225 11.9 KB

And looking through your commits on the repos provided, I don’t see anything which contradicts my assessment of intermittent activity in regards to Pocket related development. There’s certainly activity here, but much of this seems to be general Ferrum gateway development:

A burst of activity beginning at the end of May:

A test suite added this week:

I spent a little time running through the Git links provided because I wanted to understand the scale of what nine months of problem solving looked like, given that you described an ongoing effort through out that time. While I assume I haven’t seen every fork and PR yet, the described level of labor is not obvious to me in the links you’ve provided.

I’ve also spoken with the team about the timeline, and shortening the potential for it to take that long is their critical priority focus, which is why anything that takes additional engineering effort to implement starts to hit a hard wall with me. That’s also why I’m glad to see this…

…but it’s less confidence inspiring to see this as a follow up:

I do see how. In fact, I’ve seen how in the entire run of updates from 0.8.3 to 0.9.0 as the team has juggled DAO requested functionality updates, critical security patches, and other necessary core functionality, and it doesn’t always go swimmingly. Your point about the current possible delays in v1 only underscores how it’s difficult for me to put faith in your assessment of this being a low impact change without hearing that from Engineering.

I appreciate this commitment.

Or, we fulfill my RFP, and begin work now on an IBC integration which can be developed in tandem with v1, and launched at the same time, in less than 12 months, after which we transition to that method versus a custom solution. This likely also reduces the potential attack surface, since IBC is broadly adopted and audited by many developers in the Cosmos ecosystem every day.

You’ve offered to assume the engineering costs of this additional work; are you also offering to assume liability for any security vulnerabilities that arise from merging your logic with Pocket core? When we talk about our concerns with consensus breaking changes, that’s really what we’re talking about here; a new surface for vulnerabilities being introduced to the core code. Are you having third party blocksec firms audit your contributions? Will approving this not require a senior level Pocket engineer to spend hours assessing the impact of the logic which has been added to theorize and test where combinations of this logic with existing core code may create new vulnerabilities?

You’ve defended both your team and the work that team has performed passionately, and I admire that greatly, other blunders notwithstanding. But as we’ve gotten down to what you describe as being very close, I think it’s critical to have an accurate assessment of what “very close” actually means, and how many of the core concerns are being addressed here. I appreciate the time you’ve spent (especially after dental surgery, the pain of which I’m deeply familiar with), but I don’t think we’re quite there yet.

I’ve seen @blockjoe 's questions above, and I’d love to see @luyzdeleon 's take as well.

2 Likes
25

When a relationship has devolved into digging up past allegations of defamation and legal threats, I think its fair to say that relationship has run its course. There doesn’t appear to be any trust left, and I don’t think its possible to have a successful business relationship (or any relationship) without trust.

The other thing that bothers me is the initial ask of only $20k in stablecoin at the commencement of works. I’m not sure what that equates to in the USA - where I’m from that equates to 5 or 6 weeks salary for a senior software engineer. That is unsustainable business practice IMO and a big red flag.

As frustrating as it is, I struggle to see how this relationship can continue.

1 Like
26

An update here. We spoke with the Ferrum team yesterday. I sincerely appreciate Ferrum’s speedy responses here and on TG.

The feedback from everyone here has been beneficial for us and we are considering whether this is an option for v0 at this point.

Will have some more information on our thinking with wPOKT soon.

3 Likes