On Tokenomics

Last Modified Avatar

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.

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

As detailed in this document on validation

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

Token Utility Design / Fees

Fixed fee
Notes

Can't find what you're looking for?

Contact Us
Refreshed On: Aug 15, 2022 19:32:07 UTC+00:00