Binance BSA

Last updated by Tim Delhaes 6 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 .  
 
Image 1  
High Level System Architecture 
 
 
Image 2  
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. 
 
 
 
Refreshed On: Dec 05, 2022 11:22:16 UTC+00:00