Manage Gas Payments With Grindery Depay

Manage Gas Payments With Grindery Depay

A significant pain point for anyone conducting transactions on the blockchain, is estimating and accounting for gas fees. It’s not fun. Given that, we’ve begun research and development on a new system within Grindery that can address this: Grindery Depay. 

 

Do You Have Enough Gas?

Gas is the fee that is charged to successfully conduct a transaction or execute a smart contract on the blockchain. The term gas specifically refers to the Ethereum chain, while other chains and cryptocurrencies call them transaction fees, miner fees, or terms of that nature. As Ethereum is the second largest crypto by market cap, the term “gas” is often applied to transactions and work on any blockchain. 

The fees are priced in small fragments of the tokens being used, and essentially serve to compensate the validators on the blockchain, who perform the essential tasks of verifying and processing transactions on the network.

Gas fees, however, are unpredictable and are based on supply, demand, and the capacity of the network at the time of the transaction.  Hence, a user doesn’t know how much gas it will take to process their transaction prior to conducting it. While not generally a huge cost, it does mean that if someone is using the Ethereum blockchain, for example, that they’ll be required to keep ETH for the specific purpose of gas fees. Or, they will lose a small amount of their crypto balance to said fees. 

Depay is a system that may spend gas on a user's behalf across many blockchains. This route begins with the user injecting funds from their personal wallet to cover gas costs for applications based on automated workflows they have created.

To explain the process simply, we’ll focus on only one chain; Ethereum and ETH tokens. Once we’ve completed and validated our architecture, we’ll be able to extend this system to multiple chains. 

To demonstrate and validate how Depay functions regarding gas fee payments and existing services, we’ve applied the Depay architecture concept to oracles, smart contract automators and workflow applications (Grindery protocol itself). This is done via the use of specific smart contracts, Grindery’s wallet, and our token, GRT.

 

Depositing Funds

Much like any dApp, Depay starts with a user's personal wallet (Metamask, or any other wallet). From this wallet, the user can deposit ETH on the Grindery application, in order to feed their account and be able to cover their gas fees. 

The funds are deposited onto an ETH Grindery AR (Accounts Receivable) Contract - a smart contract that is used as an intermediary contract to record the funds deposited, used, and required by each user. This contract doesn’t hold any funds and has a mapping/array structure that sorts the deposits via the addresses of the users.

As soon as the funds are on the contract, they’re automatically forwarded to a global secure storage of ETH funds for Grindery users: the ETH Grindery gas wallet.

Depositing-Funds-to-Grindery (1)

In the meantime, a message is sent from the ETH Grindery AR contract, to a Grindery GRT smart contract, to mint GRT tokens that correspond with the deposited ETH. At this point, a cross-chain protocol, LayerZero for example, will create a link between the ETH information on the ETH Grindery AR contract and the GRT tokens to be minted on the GRT Grindery AR Contract. 

This contract acts as a global storage smart contract that represents the global participation of users to the Grindery network, with mapping by user and by chain.

 

How it Works

Grindery Depay is applicable across various use cases and contexts, such as using Oracles, Smart Contract Automators, and on Grindery Nexus itself. How the trigger action goes from the ETH application to the gas wallet is simple. 

 

Oracles

We’ll take Chainlink Oracles to demonstrate how Depay functions. For example, a client smart contract built on the Ethereum blockchain wants to access external information but it’s not allowed to communicate with the outside world. 

It then emits an event to request information to an Oracle smart contract that is in charge of retrieving the necessary information via three smart contracts (a reputation, an order-matching and an aggregating contract). They communicate with a network of nodes that are workers, operating independently of each other to carry out the requested jobs execution. 

In this example of a use case, the client's smart contract can communicate with the Grindery engine in order to require an adequate amount of gas fees to pay transactions associated with the Oracle work. This includes the payment of transactions between smart contracts themselves as well as the compensation of Chainlink nodes for the job execution.

 

Smart Contract Automators

Given its simplicity and applicability to all situations, we’ll use the Gelato Network to demonstrate how Depay works with smart contract automators. 

Gelato operates primarily on two layers, a blockchain layer and a Gelato layer, that either carries out or determines when to carry out actions. With notifications on Discord/Telegram that a top-up of the Gelato balance is required, Gelato presents a method in which it is possible to hold funds on the Gelato layer that are used to pay transactions. 

We can then imagine direct communication with the Grindery engine when gas fees are required.

 

Grindery Workflows

With Grindery Nexus, a user can define a specific workflow on the Grindery application. For web3 applications/DAO/dApps, actions require the payment of gas fees for each execution and/or transaction on a decentralized application. To this end, any application, based on the events emitted, can require the payment of gas fees in ETH by the user. This information is automatically transferred to the Grindery engine in a centralized manner (for the moment), thanks to listeners and orchestrators. 

A result of any of these situations, a trigger event to request the required amount of ETH tokens from the user for their desired application is sent from the Grindery engine to the GRT AR contract. The smart contract will then determine if the user has enough GRT to pay the gas fees and the status of the ETH Grindery wallet. 

Based on that, there are 3 possible actions: 

  1. If the user has the required amount of GRT on the GRT Grindery AR contract and the ETH Grindery wallet is funded, then via a cross-chain protocol, the ETH Grindery gas wallet initiates a transaction to pay gas for the desired application. 

  2. If the user has the required amount of GRT but the ETH Grindery wallet has insufficient funds, then a cross-chain transaction via a cross-chain protocol will be produced to provide ETH funds for the user. This is initiated by the GRT Grindery AR contract, and will search all supported blockchains where there are enough funds on the Grindery wallet to pay the gas fees for the application, on behalf of the user.

    For example, funds can be sent from BNB to ETH via a cross-chain protocol. Once funds are provided, a transaction is initiated to pay gas for the desired end application. 

  3. If the user doesn’t have enough GRT on the GRT Grindery AR Contract, then a request for funds is produced on the ETH Grindery AR Contract. Following this, a request is sent to the user’s ETH wallet and the funds deposited on the ETH Grindery AR contract are directly forwarded to the ETH Grindery gas wallet with a direct order for transaction for the user on the desired application.

The transaction is sent to an intermediary smart contract in order to temporarily store the needed amount of gas for the user on the intermediary smart contract before paying the gas costs to the end application. This contract connects the Grindery Wallet to the decentralized final application. 

In this manner, the contract is present for managing security and for setting restrictions on the maximum amount that can be withdrawn by the final application in order to only be able to cover gas fees (micro-payments but not large transactions). From this intermediary smart contract, gas fees are paid on the final application for the user. 

 

The Future of Depay

At present, the development of the architecture is still in progress, and this iteration of the design only takes into account one chain. We will be able to extend this system to a multiple-chain configuration once it has been verified and stable on Ethereum. This will help us get closer to the final product that will be created. Additionally, this multi-chain validation will result in the production of an advanced prototype for additional research and development. 

As a result, we’ll be able to offer an efficient and simple connection to address a common pain point in blockchain transactions; gas fees. 

If you’d like to learn more about Grindery Depay, contact us on Telegram or Discord