On Tokenomics
Last updated by Joe Hu 2 months ago
On Tokenomics
Resolving how Nexus stakeholders are getting paid is equally important to defining how the system will work technically. One could argue that defining the tokenomics before the technical aspects might even be more beneficial. Either way, they are - in web3 - inseparable. We now have a clearer technical roadmap so now it’s time to address tokenomics.
Understanding the basic economics of Ethereum Gas and the parameters of Polkadot will help thinking through it.
Understanding the basic economics of Ethereum Gas and the parameters of Polkadot will help thinking through it.
Goals
Nexus is supposed to make integrations simple. This has to necessarily include paying for them. Specially considering that payments are fragmented and as a result complex in competing systems like Chainlink.
What is simple:
Simple is for a user to pay everything (related to an integration) in the native token of its primary blockchain in a predictable manner that avoids service interruptions. For example, a DAO on DAOHaus running on Gnosis Chain should be able to pay for the service in xDAI and have a clear understanding of the project cost to be able to provide appropriate funding.
This simplification bears significant technical challenges are laid out in this document together with a solution approach.
Stakeholders
Primary Stakeholders
Somebody will have to pay for the execution of a workflow. We will call this stakeholder from now on a Customer. On the other side the Executor will get paid to do so.The Connectors are external systems but perform a crucial function that has to be rewarded: they relay information from and to the Executer of the workflow.The Validators are ensuring that the Executors and the Connectors are doing their job and will equally get a reward for that.
Infrastructure Stakeholders
Nexus requires the storage for (meta) data on IPFS/Ceramic . Furthermore, Nexus might rely on The Graph for subgraph queries and on Celer for bridging messages and tokens. Other system might be added over time.
External Stakeholders
When performing transactions on 3rd party Blockchains (like Ethereum or Near) gas chas to be paid. Additionally some services are provided by Connectors by requiere payments of external providers (like Sendgrid) making it necessary for Connectors that act as web3-Wrappers to be able to get paid in tokens.
Challenges to solve
Executing and validating multiple connector types
Possible Solutions: Workflow Insurance
<Introduction>
Customers can define the value of a workflow or in other words the economic impact of the workflow failing. (we could potentially do this automatically or at least suggest values).
Customers then pay a % of this value as an insurance for the execution. per execution or ongoing. Not sure yet.
Executers, Validator and Connectors each need to stake each the total value of the workflow (as declared by customer) for every workflow over a period of time (e.g: 30 days post processing)
If everything goes well they distribute the insurance payment between them (details TBD). If something fails they can be held liable (e.g: for up to 30 days), their stake withdrawn and the reputation slashed. Reputation could also impact the amount they need to stake.
The protocol could also incentivize people to do automated, semi-automated or manual verification/validation. The method can adjust over time and the tools for that can be developed independently.
Furthermore the protocol can be designed in a way that increased security in general increases the return of all actors making the look for ways that systems are secured collectively.
Paying for infrastructure
Solution
Signals are not free
Solution
Receive cross chain customer payments
Solution
Celar
Make cross-chain gas payments
Solution
Celar
Bridge Messages with tokens
Solution
Later
