I’ve been building meTokens at StakeOnMe.com, where we enable users with the ability to create their own novel type of personal token we call Synthetic Labor.
We created an ENS component for the dapp (video demonstration), so that users can take advantage of the fallback function in the meTokens contract. meTokens are issued by a bonding curve, so when ETH is sent to the contract (triggering the fallback), the sent ETH is immediately deposited to the curve, and new meTokens are minted and returned to the msg.sender at the current market rate.
So for example, if a user sends 0.5 ETH to stakeonme.nick.eth, the sent ETH would get staked, and the sender would receive 500 NICK meTokens in return. Simple.
There’s a UX problem, however. Sending ETH directly to an address (using its ENS domain) doesn’t provide wallets with access to the ABI for the destination contract. As a result, the wallet assumes ETH is just getting sent to another user, and it defaults to low tx gas limit at 21000 when the fallback function actually requires a limit closer to 80000. The transaction subsequently fails.
This is terrible UX. Especially in a scenario, for example, where a user shares their stakeonme ENS subdomain on Twitter where users might try to immediately open up their MetaMask to begin staking. This seems especially problematic for the ENS ecosystem in general, given the fact that there’s an ENS domain name involved in the tx, and the whole point of using ENS domains is to provide an elevated, more user-friendly web3 experience. This seems like a massive failure.
However, it also seems like a great opportunity. Specifically, for ENS to step in with a solution. I’m wondering if an ENS text record could be put to use here to publish a suggested gas limit for the contract address associated with domain. That way, when a wallet receives a destination ENS domain for the user, it can lookup both the associated address and the suggested gas limit, eliminating the chance of a bad UX tx failure.
This solution would almost certainly be put to good use throughout the entire ecosystem. After all, meTokens isn’t the only dapp that’s tried to implement this kind of feature. Uniswap created dai.uniswap.eth, so users could send ETH and immediately get DAI in return. And that contract is usually estimated to consume approximately 100000 gas.
If there’s an existing solution to this problem I would love to hear it. However, if not, I’d like to invite anyone who might be interested to help vet the idea or come up with an alternative. Any and all feedback welcome!
Many thanks!