DePay OKR Planning 16-8-22
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.
Ultimately, we can move the main contract to our L1 chain and deeply integrate it in our blockchain engine.
Definition on components:
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.
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:
Cons:
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.
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.