We are working to meet the requirements for adding GoodDollar as a gas token.
Short recap:
G$ recently launched on Celo, and will be bringing 10s of thousands of new users to the Celo ecosystem.
Currently for easy web3 experience we subsidize the gas fees for our users.
We run a faucet that any account that passed our proof of human can top his wallet from.
On top of that users of course get free money daily in the form of G$s.
This makes G$ an ideal gas token for the Celo ecosystem, to easily and seamlessly onboard new users to web3 without exposing them to complications of holding a gas token or needing to buy stables as an alternatives.
G$ is also “always liquidty” and “stable enough” due to its tokenmodel based on the Bancor Reserve model, which also makes it relatively secure and trusted for validators.
Another idea is that gas fees paid in G$s would go back to fund more UBI as per the vision for the Celo protocol to support UBI.
So far we’ve implemented the debitGasFees and creditGasFees requirements, we’d appreciate code reviews here:
We are looking for some guidance regarding the price oracles:
You need more than one USD pair at exchanges whose price feeds are accessible by API (via ccxt, right now). The Oracle handles time and volume weighted averaging, circuit-breakers, retries, etc.
The current model assumes more liquidity for gas tokens at centralized exchanges, than on-chain. This is not necessarily the right assumption for some tokens, especially in the future, but was true for the first use cases for the Celo Oracles.
If most of your token activity is on-chain, this model might not work for you. @roman@martinvol@bowd might have some more thoughts.
yeah G$ is not on any centralized exchanges.
We have the reserve on mainnet which is based on Bancor AMM and has a subgraph
And we’ll have some pools on Celo
But I think the bigger challenge is that the current model needs rethinking/extending for on-chain tokens. There a few different ways to solve this, but all would need new core contract code (and possibly a blockchain change)
In theory, the oracles can watch the price on-chain and calculate the TWAP. The client just calls an API and forwards that price on-chain, but there’s nothing stopping from getting the price for an on-chain source.
Worth noticing also with the current model, the client is needed, even if TWAP is available somewhere in the chain.