Last updated by Tim Delhaes 2 months ago
Grindery is an early-stage, BinanceLabs S4 project with funding from Near , Algorand, Flow and Harmony . Grindery Nexus is a “middleware for web3”. Think of a Zapier for web3. It's a decentralized system that can interact with smart contracts as well as web2 APIs. It allows to define workflows with time, state and event triggers to execute smart contracts as well as API (web2) transactions. In short, unified, seamless on-, off- and cross-chain integration . The main purpose of this system is to increase interoperability of dApps . We do this by allowing dApps to provide their users with DIY integration features .
The system is currently at early prototype stage and we are deploying on Polkadot Ignite or Binance BSA as substrate/sidechain.
High Level System Architecture
Unified, cross-chain Tokenomics
Grindery is focused delivering value to three types of users:
Allow any user to easily configure their own integrations without using code. An example would be a user creating an email notification through Sendgrid whenever they receive a deposit in their wallet.
Allow developers to build integrations as secure self standing dApps for specific systems. An example would be a DAOHaus Boost that allows DAO members to submit payments requests via a Google form and then batch and pass them on-chain as a proposal to the DAO.
Allow dApps to launch their own integration marketplaces. Pretty much what every major SaaS company does today. Just for Web3. Some existing web3 examples include Gnosis Safe dApps available inside the Gnosis Safe dApps.
Our ultimate goal is to make creating and reusing integrations as simple and fast as possible and needs to overcome several challenges to build a fully decentralized system.
Our core strategy to achieve this has three main pillars.
First, we will run all workflows logic on a single chain compared to current Oracles Network (Chainlink) and Automators (Gelato) where all logic is implemented chain specific. This increases reusability of integrations and simplifies implementation of workflows. The trade-off is this is the increased security risk resulting from the fact that every workflow execution will require inter-chain communication. Initially this risk is low though because we focus on web2-web3 and web3-web2 integration rather than bridging tokens between chains.
Second, we will unify the tokenomics of the entire system. Making it easy for users to pay for the service in a simple way is as challenging as the technological challenges of the workflow's messaging itself. We want to allow all users to pay everything (related to executing a workflow) in the native token of his 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. To achieve this we will need to create or leverage bridges between chains.
Finally, because Nexus has different inbound and outbound messaging capabilities for web2 as well as web3 protocols our Connectors need to be upgradable. For example a Web2 Connector could communicate data with a Google Sheet API and a Web3 Connector could communicate with the Harmony Blockchain. Because of the nature of the different protocols these connectors will require different validation processes. For example a new row in a data sheet should be detected within a minute while a blockchain event should be detected in real time. As a result Nexus needs to support upgrades to the Connector execution and validation in the runtime of the system.