With the basic primitives of HTLCs and PTLCs in place we can now begin development of a truly decentralized p2p trading market.
Bridges will enable us to provide liquidity where people expect it now.
We will build the liquidity of the future.
As Vitalik says in his recent Sunday post:
Cross-chain bridges: similar logic as oracles, but also, try to minimize how much you rely on bridges at all: hold assets on the chain where they originate and use atomic swap protocols to move value between different chains.
Later today, we will release a test build of Syrius which (thanks to Vilkris) has a best in class Atomic Swap UI. We will also be posting instructions on how to join our testnet so that everyone can try Atomic Swaps and begin experiencing the P2P Revolution.
This is just the first step, and there are a lot more possibilities when it comes to the potential of P2P, such as orderbook based interfaces.
I am asking a minimum of 150k ZNN, 1.5 M QSR for myself and other team members for continued work in this direction.
I see no answers and therefore will vote no to any further A.Z requests related to atomic swaps. I encourage all the pillars to do so as this technology never got adopted and nobody is able to tell us why we should implement it. Dull p2p markets are useless.
Among the HyperCore One team members there are no formal hierarchies or giving of orders.
All participation is opt-in.
Naturally, different team members have different talents and interests. So different team members will take on leading roles across the end-to-end delivery lifecycle.
One team member may be leading implementation in a certain area while other team members are testing, learning, peer reviewing code, and contributing to design. In a different area, the roles may be reversed.
I suppose the next question that would make sense to address is:
Why such a large ask?
Our holistic end-to-end delivery model means that we will work with the community to create larger milestones where the value can be experienced or shown through data.
But this model also incurs a significant amount of overhead.
While this overhead greatly enables us to deliver the value that the community needs in a fast and iterative manner, it doesn’t always make sense for these things to have their own AZ proposals.
Some current examples:
We intend to maintain production quality binary builds. This carries security, integration, and testing burdens. We’ve started offering public testnets and related infrastructure such as faucets and explorers.
The go-zenon codebase includes various hardcoded IDs such as spork ids and the new bridge and administrator addresses that don’t work well with testnets. So we created a backwards compatible patch that would allow these values to be configured. Over time, we will productionalize this solution. A lot of other tooling such as controllers will need to be made compatible with testnets.
Taking a holistic approach also means being aware of other work happening in the community. Oftentimes this means testing and validating the work of others in a systematic way. It means road-mapping and maintaining dynamic plans for future work.
As the ecosystem grows, this overhead will grow alongside it. In order to justify maintaining this overhead, we need a significant commitment from the community, so that we can recoup these costs over time as we deliver incremental value. This commitment will enable the five HyperCore.One team members to focus on end user value instead of worrying about if all the incidental costs will be covered.
In the next few days, we will begin working with the community to create a milestone/payout framework that the team and the pillars will both find agreeable.
As mentioned in our previous posts, all HyperCore.One participation is opt-in.
There are also some items of work that team members have delivered or are wrapping up that will fall outside of the new milestone/payout framework.
Ty ty for the elucidation ser. I’m absolutely certain everyone in the community is grateful for your team’s efforts and dedication to our ecosystem. A couple of questions:-
i) This is a very big ask and a very specific amount- how did you come to decide upon this 150k ZNN, 1.5m QSR no.? What does it come with- how many months/years of commitment can we expect from your team? Is this a full-time commitment to the Network? Is the plan to give each of the developers on your team their own pillar(s?) to run (not against this- in fact I quite like the idea of developers running pillars and taking an active part in network governance)?
ii) Would it be possible to get an introduction to the team (though I’m sure we should be able to hangman most of them) or for the team members to introduce themselves? What are their specific skillsets that they are bringing to the forefront? I do not doubt our community developers but since y’all are applying for a considerable grant- I’d like to know what all we’re potentially paying for.
iii) Finally, if the “ecosystem grows” the values of the rewards that you will reap from your pillars, sentinels, or from delegating, staking or LP’ing will proportionally increase. Can we come up with a payment plan that potentially takes account of this? Perhaps your team can requests payments of this large grant in batches/instalments? This way if the price value of ZNN/QSR increases the amount requested can be reduced. This can help ensure that our AZ Warchest doesn’t deplete at such an accelerated (haha) rate.
Are you guys curious if PTLCs can be used for something other than an atomic swap of 69 ZNN <> 420 QSR between Alice and Bob? Don’t you guys have the feeling that someone knows EXACTLY how we will interoperate with BTC?
Based on the work this team has already performed, and continues to perform ie Eth Bridge dependencies(95kZNN get us what again?) + ongoing Syrius upgrades + every new problem that comes up… we are already relying on this group for basically all ongoing development. Would be highly regarded to shut down their efforts. Negotiating the amount proposed for payment is fair though, would be a great conversation for the community to get comfy with.
This is all aside from the fact that BTC interop is completely built around P2P so clearly i am in full support of the HCone efforts.