Grindery Nexus

Last updated by Tim Delhaes 3 months ago
Think of Grindery Nexus as a Zapier for Web3. 
At its core, Grindery Nexus allows end-users (with a no/low-code UI) and developers (with a simple declarative language) to define multi-step workflows that connect smart contracts across chains to off-chain systems. The Web2 APIs and Web3 chains that can be accessed depend on the available “Connectors” (also called Signals and Gateways). These Connectors can be built and operated permissionless by anyone. The workflows themselves are executed and validated by a network of nodes that get paid by the end-users (or dApp) in tokens. 
Image 1  
(9) Grindery Nexus high level architecture 
This architecture makes Grindery Nexus a feature-complete, composable automation system that allows blockchains, protocols, dApps, and APIs to integrate. The reusability and payment of the connectors create a strong network effect enabling a vibrant ecosystem. The system integrates and complements existing Web3 infrastructure like The Graph, ChainLink, Ceramic, Celer, etc. 
Image 2  
(10) Grindery Nexus further decentralized the dApp Stack 
The system has four main stakeholders: 
Developers of Web3 dApps who want to deliver better DIY integration to their users. 
End-users (or “customers”) who can create, use, and pay for integrations with no/low-code. 
Developers who create reusable connectors to existing Web2 SaaS Apps and APIs. 
Blockchain APIs and nodes allowing Grindery to detect events and execute transactions. 
How these stakeholders use the platform is best illustrated with our DAO example. 

Creating an interoperable dApp 

How does Grindery Nexus create value? We’re using our example DAO. But rather than creating an individual integration, we will create a Moloch extension called a “Boost” that can then be reused by any other DAO. 
In preparation, a developer would create reusable connectors for Google Sheets and SendGrid. This effort is somewhat similar to creating a ChainLink Adaptor. The Grindery Connector can then be reused by other dApps (including other DAO frameworks like AstroDAO, Aragon, etc). If the connector already exists, this step can be skipped. 
A developer can then develop a Boost[13]  connecting to the Grindery API and customizing the end-user experience using simple JSON parameters and JS. Grindery takes care of storing the users’ credentials, settings, and transactional metadata. The Boost is then added to the DAOHaus marketplace, making it available to all DAOs. Under the hood, this creates two declarative, multi-step workflows. 
Image 3  
(11) Actions and triggers are defined as JSONs 
A DAO member could now find or discover the Boost on the DAOHaus marketplace and install it, making it available for the DAO. By configuring the Boost’s settings, the Google Form, as well as the automated email notification, becomes available to the DAO members. 
Image 4  
(12) Grindery Nexus powering DAOHAus Boosts 
To see the demo in action . 
Furthermore, any developer could create a “wrapper” around the SendGrid service that allows receiving tokens to send emails by the DAO and pay SendGrid for the API usage. This is a centralized service that could be provided by the DAO Platform (e.g., DAOHaus) or any 3rd party. This would allow the second workflow (triggered by the approval of the proposal) to use the “wrapper” instead of connecting to the SendGrid API directly. 
Image 5  
(13) Enabling payment of Web2 services with tokens 

 

The Nexus dApp 

Grindery will incorporate its technology into its existing “legacy” (d)Apps, including gPay  (decentralized payouts) and gWork (contracts and timesheet management solution) to test and showcase the Nexus platform. This also creates reusable open-source code for our developer ecosystem. However, at the core of Grindery’s dApp development is the creation of the Nexus dApp that allows anyone - similar to the Zapier web app - to configure any integration using existing connectors with no code. We will be addressing sample use cases for this dApp in the following paragraphs. 
Image 6  
(14) Introducing the Grindery Nexus dApp 

System Overview 

Users define workflows - in our Nexus dApp or any other dApp - consisting of one trigger and at least one action. Triggers are defined by an event and additional conditions. Events are WebSocket messages emitted from other systems, including blockchain APIs (Alchemy, etc.) and encapsulating services for Web2 APIs (Google Sheets, etc.) that translate HTTP to WebSocket messages. We call the systems that emit compatible messages signals or signaling services. A signaling service can be a Blockchain API (like Alchemy) or a wrapped Web2 API (like Google Sheets). Until the system is decentralized and delegated to nodes, the service is built, hosted, and maintained by Grindery. 
Image 7  
(15) Grindery Nexus will be decentralized progressively 
Every signal is declared in the system through a Signal JSON - similar to a smart contract ABI (Application Binary Interface) - that describes how the message can be interpreted and as a result, provides end-users with a simple, no/low-code interface. 
Another core feature Grindery provides is the credential manager. It stores user credentials securely and performs HTTP requests to service the API directly, without exposing credentials to other nodes. This allows users to subscribe to private signals like specific Google Sheets or other Web2 Apps. 
Once a message from a signal has been received and the conditions of a trigger - such as the amount of maximum repetitions, gas prices, and other variables - are met, the actions start to be executed. The trigger conditions are an extendable library, and more conditions will be added as the usage and use cases of the system increase. 
Once triggered, the actions of a workflow are executed by the workflow engine. This is again initially done by a hosted service but will then be broken down into multiple sub-functions executed by nodes in the network. 
Actions that are performed by the workflow engine fall into two categories: Web2 actions and Web3 actions. 
Web2 actions are essentially HTTP calls to public APIs or private APIs (using the credential manager). We call these APIs Web2 Gateways because these APIs are - similar to the signals - described as JSON, and Gateways can receive tokens as a reward for their service. 
Web3 actions are similar to tasks of other smart contract automators. They allow for the execution of smart contract transactions on behalf of the workflow owners. The required gas is paid through the workflow engine using funds from the users’ wallet and will be detailed in the next chapters. Every blockchain requires its own implementation of the connections to the specific blockchain. The description of these Gateways is also stored in JSON format in the system. 
Additionally, the workflow engine stores extensive meta data when a workflow is executed. This meta data is then made available to the workflow engine and the end-users for use in their dApps. 
The combination of these components produces a uniform yet composable architecture that can grow and adapt to new use cases to connect Web2 and Web3 systems seamlessly. The hosted version of this system can then be decentralized. 

Key Features 

The primary differentiator of Grindery Nexus is its ability to create interoperable dApps with DIY integration for their users. This ability is driven by a few fundamental technical features and characteristics: 
Workflows are stored as a simple and easy-to-edit format. 
Workflows support multiple steps, delays, transformations, and later, branching. 
On-, off- and cross-chain workflows are declared in the code. 
Support for all types of blockchains including EVM and WASM. 
Triggers can be time-based, blockchain events and states, and (Web2) API events. 
All connectors are created once, and reusable for all workflows. 
Connectors can receive payments for their services. 
The system produces metadata that can easily be accessed. 
The workflow engine has a fully distributed architecture. 
 

Use Cases 

Grindery is discovering new use cases for its technology. In general, we are grouping all use cases into two groups: 
 
One group consists of developers that use Grindery Nexus to add DIY integration features to their dApps. 
The other is: end-users creating integrations for personal use using the Nexus dApps. Both go across categories and have several overlaps. 
 
3rd party dApps with DIY integration 
One area with interesting use cases are DAOs. Not only in creating specific integrations, but rather, allowing DAO Frameworks such as Aragon, MolochDAO (DAOHaus), Colony, xDAO, TributeDAO, AstroDAO, DoraFactory, Prismatic, Syndicate, or recently, Common, to launch their own dApp and integration marketplaces. We will address this further in the go-to-market section. The same opportunity applies to Multisig Wallets such as Gnosis or Multisig. Example use cases include: 
Detecting and batching multiple invoices from Web3 dApps such as Smart Invoice, Request, or Bulla, to a DAO for voting and approval. Then transferring funds back into dApp for contract execution. 
Detecting new recurring salaries in an HR software like BambooHR or Gusto, passing them for approval as proposals to a MolochDAO, and then starting a stream in SuperFluid once executed. Then writing the resulting metadata to Xero, Quickbooks, or Netsuite for accounting purposes. 
Another area with a lot of different use cases is in the intersection between Grindery and other infrastructure tools such as The Graph, Celerm, ChainLink, Ceramic, and others. Grindery can add significant value (and increase usage as a result) to those systems. 
Finally, almost every dApp across all categories can benefit from Grindery Nexus’ ability to rapidly implement browser, email, and mobile push notifications. Many dApps, including wallets, lack basic functionality to notify users of critical on-chain events that can enhance security and more importantly, increase usage and user retention. 
 
Empowering end-users with the Nexus dApp 
Similar to Zapier in Web2, there are literally hundreds of possible integrations that create value for individual users. Some of them are listed here. 
Send users a browser notification when a deposit on any of their wallets on any chain has happened. 
Artists can set up automatic NFT minting based on certain conditions like holding a certain amount of tokens, accessing specific dApps, interacting with a website, a Google Form, or buying an object on a marketplace in a virtual world. 
Allow to automate yield farming, by listening for LP rates changes and moving funds from one LP to another (e.g., Aave to 1inch). 
Allow users to configure automatic trading strategies without writing code. For example: buy 1 ETH every day; swap any ERC20 token when a specific ratio is met. 
Detect Google Forms submissions on a website, initiate the minting of a token, and send it to the submitted wallet address. Then, update the Google Sheets data with a transaction timestamp and transaction ID. 
There are so many cases out there and the most exciting ones - for us - are those we have not yet discovered. 
 
 
Refreshed On: Sep 23, 2022 07:29:57 UTC+00:00