DePay OKR Planning 16-8-22

Last updated by Tim Delhaes a month ago

Question: What are the next steps to define how we implement universal cross-chain gas payments (Depay), leverage Grindery for it and male Grindery ultimately a L1 (on Polkadot ? on Cosmos?)

DePay and L1

Cross-Chain Gas Payment

My idea on this:

We probably need to launch our token first, main contract of the token can be on any stable EVM chain. Polygon can be a good choice for its low transaction fee.

Build a "gas pool" smart contract and deploy it to all supported EVM chains. The smart contract receives native (gas) token from user address, an external app in our infrastructure listens for the transfer event and credits some tokens to user address on our main contract. Essentially, this acts as an one-way bridge for buying our token.

When we call a smart contract on behalf of user, we log it on our main contract, which will charge user for some amount of the token. Gas fee of the transaction is paid from our own wallet on each chain and initially we manually replenish our wallets to ensure they have enough funds, later we can automate it.

Amount of crediting and deducting can be determined by live exchange rate.

Ultimately, we can move the main contract to our L1 chain and deeply integrate it in our blockchain engine.

Definition on components:

Gas pool contract:

Receives payment from any address and emit events for each transaction

Allows authorized addresses to take out any received tokens

Main token contract

Standard ERC-20 token interface with ERC-1067 upgradability support

A function for crediting or deducting token to/from an address with 2 input: chain and amount. The contract should query live exchange rate and transfer token based on the result.

App for listening for events from gas pool events and send them to main contract (3 ~ 6h)

All the contract should be implemented in an upgradable way.

Questions

(1) What are the pros and cons of EVENT vs a STATE based system?

Event-based system is relatively straightforward to implement. I actually can’t imagine how to implement it as state-based in a good way, do you have any idea in your mind?

(2) What would be the pros and cons of using Grindery vs Celer, Router, etc?

Celer and Router can be our options for notifying the main contract to credit user with token after receiving fee token in source chain.

Pros:

No need to set up an external app for cross chain messaging

Cons:

Limited by supported chains of Celer /Router

Need to maintain fee wallet on each chain (compared to external app, which only needs one operation wallet on the main chain)

At the core: what are the security concern here?

Since we only support one-way transfer initially (we may also process refunds manually if needed), security exposure is limited, we will only need to ensure that only our wallets can call privileged functions (credit/deduct tokens to/from an address) and take out funds stored in the smart contract.

[From Slack] only if we have clear answers for (1) and (2) we will be able to answer if and where running as L1 will provide value for this scenario?

For this specific scenario, I don’t think running it as L1 can provide a major benefit over running it as smart contracts + external app / Nexus.

2 tokens/chains. test net. Allow to deposit and use gas with Grindery workflows.

We can now "fork" (1) to become gas payments 1.0 for ur live product. Audit it. Add chains.

introduce GRT token on another chain. use manual process to credit/debit pools but allow cross chain payment. Rely on Oracles but still manual process.

automate the process. Do research and use Grindery as well as other technologies to see what works best and why. Intensive work.

If Grindery turns out to be the best option evaluate what L0 would not add most value and why.