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