On Tokenomics

Last updated by Joe Hu 6 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. 


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.  


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 

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 




Signals are not free 




Receive cross chain customer payments 




Make cross-chain gas payments 




Bridge Messages with tokens 




Token Utility Design / Fees 

Fixed fee 
Refreshed On: Dec 06, 2022 12:36:46 UTC+00:00