Grindery Payment Rails

Last updated by Joe Hu 5 months ago
TLDR: Grindery will build a secure, subscription model 



Making payment easy for users, especially for B2B software, is not only required for adoption but is one of the inherent challenges of any system. Easy and secure payments (tokenomics) are a challenge to Grindery Nexus equality as big as the automation technology itself. And likely deeply interdependent. 
What do users want? Looking at web2 the dominant form of payment - used by thousands of SaaS companies- are credit cards based recurring subscription. They have found massive adoptions because of many reasons for customers and merchants alike 
Merchants can offer (usually) easy to understand, monthly or annual subscription plans 
Use of stable (fiat) currencies produces predictability of cost and income to both stakeholders 
Merchants native currency is hidden and irrelevant to customers payment 
Once approved subscription are charged automatically in the background 
Merchants package and hide all cost (servers, licenses, business operation) conveniently 
Payment amounts are relatively small and perceived risk and resulting trust is high 
Credit card merchants are validated by multiple entities (bank, payment gateway, card, etc.) 
Credit cards are insured against fraud 
In Web3 providing this level of convenience, specially when building entirely decentralized systems, is extremely challenging due to lack of blockchain interoperability. 
Some examples of this include 
 In the case of Grindery Nexus some of the challenges are 
Customers might perform transactions on multiple chains requiring gas tokens for each chain. 
Customers needs to pay workflow execution on a chain different from his own requiting customers to possibly bridge and swap tokens to make simple payments. 
Customers need to pay services of app like email or SMS automations introducing yet another token and possibly a chain. 
Cost of operating the workflow engine like storage (IPFS/Filecoin) and queries (The Graph) might be difficult to be covered by individual nodes 


Our goal is to make payments for web3 automation as easy as in web2. Zapier charges a recurring subscription charge that is easy to use for everyone. We want to allow the same for Grindery Nexus, leverage our own technology for it and produce a reusable, open source framework for other use cases at the same time. 
Our ultimate goal is to allow customers to pay all fees, securely in the gas token of their primary chain. For example a MolochDAO on DAOHaus using GNosis chains should be able to pay for the workflow engine, the gas on any chain and additional services (like email or SMS) with xDAI only. NOTES 

System overview  

User registration  

All users, customers and merchants alike, create Grindery accounts using Ceramic 3ID and a non-custodial Grindery wallet. 

Merchants Setup 

Merchants can create  payment plans.  These payment plans can specific recurring subscriptions, one time charges as well as charges per transaction. The definition of each plan is stored as a JSON (also called PDSm Payments Definition Schema) on IPFS together with the merchant's wallet address. This creates the equivalent to a Stripe Merchant account  with flexible pricing options.  
Merchants also stake Grindery Tokens equivalent to charges they will do to customers. This allows it to create the equivalent to a credit card or ACH insurance where customers (or Grindery) can revert transactions for a defined period (like 30 days). It also allows to establish reputation and ways of punishing bad actors.  

Customer Setup, funding and subscription 

On Grindery Customer can create a deposit address on their native chains (e.g: Gnosis Chain for MolochDAO example) using the non-custodial wallet of the user. This wallet is in turn tied securely to the users Grindery account and Grindery wallet using 3ID. This creates a bond that allows to associate gas token deposits of the customer on any of the customers chains securely to grindery accounts and wallets. 
Customers can now deposit gas tokens in the depot address on their chain. These deposit accounts can be considered the equivalent to prepaid credit cards where merchants can - indirectly - draw funds from these accounts are collectively labeled as “pools” can will - as shown later - be leveraged to pay gas fees of the same of other users on that chain. 
Grindery Nexus will detect all deposits in these pools and credit customer users with the equivalent of Grindery gas tokens in its pool on its chain. The user does not actually receive any tokens to its wallet nor are any tokens minted, burned, locked or otherwise bridged. The customer’s credit is merely an “IOU” on the Grindery chain. In combination with multiple proven security strategies - including staking of validators - this approach provides near to zero risk compared to general purpose token bridging. 
Furthermore customers will not be able to withdraw deposited gas tokens (e.g: xDai) from any of the pools. The ability to withdraw funds will be limited to the Grindery protocol only reducing risk of pool drained accidentally or by malicious internet. Customers will however be able to withdraw their deposits on the Grindery Chain as GRT at any time use publicly available bridges and swaps to freely exchange them. 
Customers can now “purchase” services of merchants. Essentially a purchase is an authorization of the customer for a merchant to draw grindery tokens from the Grindery Pool with certain conditions. When a customer purchases the information, it creates an Access List (ACL) as a merkle-tree , similar  to a merkle airdrop , and stores it savely on IPFS. The ACL contains the merchants wallet address, payment amounts and conditions as well as the customers Grindery and source chain wallet address. The resulting hash is passed to the Grindery Pool contract allowing merchants to now withdraw tokens from the pool according to specific conditions and tightly associated with all customer data allowing the information to be used on all relevant blockchains for executions and validation. 

Merchant withdrawals  

To get paid merchants simply call the Grindery Pool with the merkle hash generated from their wallet address and the publicly available ACL. The smart contract now calculates the authorized withdrawal amounts based on the purchase parameters of all the customers purchases. The calculation also offers the opportunity to calculate exchange rates between the grindery token, the customers gas token and any stable fiat currency to reduce volatility. Before transferring tokens to the merchants wallet the contracts assures that the merchant has sufficient amount of staked tokens.  
This approach allows merchants to conveniently withdraw anytime all the accumulated  payments at once while providing the customer (and grindery) with the opportunity to dispute charges over a predefined period of time.  

Grindery Gas Station 

The Grindery Gas Station is another merchant with the authorization to pay gas in behalf of the user. 

Grindery Engine 

Grindery Engine is another merchant. Initially a hostd service. Laters a network of nodes. 
Refreshed On: Dec 06, 2022 11:11:35 UTC+00:00