Grindery Network OLD
Last updated by tim 10 months ago Grindery Nexus will launch as a hosted service, similar to The Graph[14] , and decentralize over time into a network. This allows for rapid prototyping and quick iterations to achieve the best product-market-fit. Subsequently, the objective of decentralizing the technology is simple: by moving workflow execution from a hosted service to a distributed network of Nodes. The operators of these servers will need to be paid, and it needs to be assured that said operators can not manipulate the network. Failure redundancy should also be provided.
(16) Grindery Network and Marketplace
In essence our Signals have to become oracles for on- and off-chain data. Grindery extends the concept of oracle to Gateways for verifiably writing data to on- and off-chain systems. As a result, the workflow logic can now be defined and processed using a simple, uniform, declarative language. It creates a marketplace that brings together multiple parties: First, end-users and developers who want to automate their dApps. Second, operators who are looking for workflow tasks to complete as instructed by users for a fee. Third, operators of connectors that provide services that can be consumed by the dApps for a fee. Finally, Web2 services and Web3 protocols that want to enable DIY integrations.
This requires the system to:
(17) Grindery Nexus Network Architecture
System Components and their functions
Signaling services receive HTTP API events from Web2 apps and Web3 providers, and send WebSocket messages to Listener nodes. They are validated and rewarded by the nodes of our network and the nodes compare signals to generate a consensus to avoid malicious behavior and errors. Signals are free and can receive rewards depending on what and how often they reliably trigger workflows. Each signaling service is validated and approved by Grindery DAO before it can be used in workflows.
Event Listeners subscribe to messages from signaling services and can receive the same message simultaneously from multiple signal services. Once a signal is received it is sent to the Orchestrator node to validate and dispatch workflow as appropriate.
The Orchestrator is the brain of the workflow engine. It maintains a list of all workflows, dispatches triggers to signaling services, dispatches workflow actions for execution and validation, and submitting execution results to persistent storage (IPFS/Ceramic).
An Executor is responsible for reliably submitting transactions via blockchain gateways on-chain as well as sending data via HTTP to Web2 gateways. Executors receive actions to be executed via the Orchestrator. All Orchestrators are connected to all Executors on the network, and when an action becomes executable, it is shared among Executors selected by a predefined algorithm. As soon as an Executor receives an action to be executed, the Executor usually performs a simulation, and if the simulation does well, the Executor submits the transaction via a gateway to the blockchain or Web2 API. In the case that a task execution needs a resubmission, the Executor can - if applicable - be responsible for bumping the gas price and re-submitting it.
The Validator checks the correct execution of the workflow step and returns the result to the orchestrator.
Gateways encapsulate a Web2 service or Web3 blockchain into an interface of composable actions. Gateways are operated by gatekeepers, who receive payment from users as an incentive. A gateway can be operated by multiple gatekeepers to avoid a single point of failure. Each gateway is validated and approved by Grindery DAO before it can be used in workflows.
A Workflow Lifecycle
A user creates a workflow on the frontend dApp or programmatically, the workflow JSON is saved to IPFS and then its CID is submitted to a smart contract.
The transaction is picked up by the workflow Listener, which will save workflow data to the internal cache database.
The Orchestrator node notices the new workflow in the database, and picks an Event Listener node, and sends over trigger information, which contacts the appropriate signaling service to set up the trigger. The Orchestrator node can also optionally set up the trigger with more than one listener node and only react to a signal when it is received from all listeners, and they are identical.
When a signal arrives, the Signaling Service sends signal data back to the Event Listener via an active WebSocket connection, which forwards the data back to the Orchestrator.
Upon receiving the signal from all subscribed listeners and validating that they are identical, the Orchestrator picks one (or more, for redundancy) Executor nodes and sends over details of the first workflow action step.
The Executor will first test the step to ensure it meets execution conditions (like gas limit), then execute the action by constructing and sending a request to the appropriate Gateway, which sends the request to Web2 service or Web3 blockchain provider. The result and execution metadata returned from the Gateways is sent back to the Orchestrator.
After getting the result from the Executor, the Orchestrator sends the result to one of the Validator nodes. Validated result and data is saved to IPFS, the execution summary of this step is submitted to a smart contract, which will emit it as events for a future query, and send reward and necessary payment to all nodes and connectors participating in the execution. If there is an issue, the step is re-dispatched to another node if appropriate.
Grindery Tokenomics
Grindery’s mission is to enable DIY integration for 3rd party dApps. This requires payments to be as simple as possible and ideally as easy as the actual integration. The customer (or end-user) will need to pay for three separate services:
(18) Multi-chain and multi token payments
The challenges of these payments are:
There will likely be three different tokens. Grindery nodes (1) have to be paid in our own network token to enable staking and governance. The gas for the transaction (2) needs to be paid in the native token of any of the blockchains we support. The service provider will want to get paid in a stable coin (3) to minimize volatility.
The payments will often be on two different blockchains but could be on more, as Grindery workflows work across chains.
The user needs to maintain a reserve of one or multiple tokens for workflows to execute properly. Given the laziness of smart contracts and the multi token/chain complexity, users might not notice a lack of correct funding.
Addressing these challenges is of vital importance to creating a fluid economy. For example, in other networks, the ChainLink nodes are paid in $LINK token while the node needs to pay gas in the blockchain gas token. The fact that the node has to swap and potentially bridge tokens is a major inhibitor for utilizing node transaction capabilities. In fact, there are hardly any tangible examples of real life use cases in the ChainLink ecosystem.
Grindery addresses the challenges in the following way:
The nodes and the service providers will be paid on the same blockchain with two different tokens. While Grindery Nodes will receive payment in the Grindery token, service providers will receive a stable coin, as to not have to deal with the volatility of the network token. We are still researching to decide on the blockchain and the stable coin we will use.
Users should have the ability to use a single token native to their network to be able to cover all payments. This could be achieved by automatically bridging and swapping this token and/or using it as collateral. We have experimented with this concept in past prototypes and will rely on protocols like Celer to implement this as they extend their cross chain functionality and support for more chains and tokens..
Grindery allows integrating the funding contract/wallet with Multisig Wallets and DAO frameworks. When funding runs low, Grindery automatically triggers a funding request (via a proposal) to the DAO and/or creates easy to fulfill funding requests to users’ wallets.
(19) Simplify and automate all payment aspects
Grindery Token
The Grindery token exists as a utility for the effective incentive alignment amongst all relevant platform participants - gateways, signals, developers, users, and nodes. The tokens also serve as a means of governance to signal their support or opposition to proposals in the Grindery DAOs.
The token can be utilized for the following purposes:
Operating the network
Nodes, in order to be able to participate in running workflows in the Grindery Network and thus earning rewards from doing so, will need to acquire and stake tokens. Staking will grant node operators the right to earn fees from running workflows.
Potentially slashing the stake of node operators will serve the purpose of disincentivizing bad behavior, such as censoring a workflow step, making such actions uneconomical. The Grindery DAO will have the power to enforce these decisions and the obligation to monitor the behavior of node operators. Node operators will become more accountable for their actions which will enable us to further decentralize who can run these nodes.
The control of the nodes will thus be distributed to the dApps and developers that are using Grindery the most, by overseeing the protocol and influencing the decisions within the infrastructure of the network. The infrastructure is designed to extract as much value out of the system to ensure that they continue to operate in the best interests of the end-user.
Governing the Network
All token holders are able to have a say in the future direction of the protocol via voting on proposals in the Grindery DAO. The goal is that in the long run, developers that use Grindery will govern over the protocol in order to determine the “rules” by which the Network will have to adhere by.
Decisions include setting fees for Executors, deciding on developer incentive schemes, and enforcing that Executors always execute transactions in the best interest of the end-user.
Social Validation
The Grindery team is actively exploring strategies of “social validation” of workflow execution and results. We expect to conduct further research into this in Q3-Q4 2022 and will publish our findings in due time to share with the community.
Grindery DAOs
Grindery is an open-source and community-driven project and is governed by the people who use it most: its users, developers, and operators. After the Grindery token is released to the public, this will become possible. It will ensure Grindery’s success in the long run — to minimize the fees and value extraction, optimize the reliability and user-friendliness, and assist Grindery’s mission.
The Token Holders’ responsibilities are to ensure the system operates sustainably in the long run and that workflows are getting executed reliably and cost-effectively as well as to approve new Connectors.
Grindery will form sub-DAOs for developing their relationship with developers on the different blockchains. These DAOs will implement continuous (or better, infinite) investment, grant, and bounty programs that will drive the breadth and depth of automation capabilities on each participating blockchain.
Planned token allocation
Grindery has not yet finalized all aspects of its token issuance, including token launch, token amount, and other dynamics. We do not foresee important inflationary or deflationary mechanisms in our tokenomics, but we might adjust according to the outcome of our ongoing research. The table below reflects the intended token distribution as of June 2022
Group | % | Subgroup | Allocation | Cliff | Vesting |
Early backers | 27% | Grindery Inc (USA) Team/Founders | 5% | 1Y | 3Y |
Team (reserved) | 5% | 2Y | |||
Grindery Inc Investors | 1% | No | |||
Early investors (TD) | 7% | ||||
Advisors, FFF | 1% | ||||
(reserved pre-seed) | 8% | ||||
Future token holders | 73% | Future investors | 20-30% | No | 3Y |
Team, Community, Foundation, Network Nodes, etc | 43-53% | TBD | |||
Conclusion
The Grindery token is a pure utility token used for payment, governance, and staking. There are no expected cash flows associated with it. The token will have no value other than providing developers and users with the ability to attract better performance. The token has no inherent financial value attached to it whatsoever and is purely a utility for enhanced usage of the platform and its prolonged maintenance and development.
When the token is launched, several use cases will already be live, and some already existing nodes are earning stable revenue from their infrastructure as a service fee. The token will be used to steer the project into the future, enabling all network participants to take an active role in governing the system and making sure all their interests are represented and aligned.
