Grindery Payment Rails - Celer

Last Modified Avatar

Last updated by Tim Delhaes a month ago

TLDR: Grindery will build a secure, subscription model

Introduction

Challenges

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 wnat? 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

Solution

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 wallt 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 deposit 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 walet 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 protol 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.

Can't find what you're looking for?

Contact Us
Refreshed On: Aug 16, 2022 04:39:35 UTC+00:00