Gnosis chain withdrawals with claim tx

dapplion · June 7, 2023, 7:58pm

Gnosis chain withdrawals are coming soon with the Shapella fork. Their logic is very similar to Ethereum except that the withdrawn token is an ERC20 instead of the native chain token. So Gnosis chain execution clients execute a system transaction as part of block processing to distribute the ERC20 stake token.

Problem

However this approach has an important flaw. System transactions do not produce a receipt, so any log emitted as part of execution is not reachable in any way. So the bridge GNO token won’t adhere to the ERC20 standard anymore because the Transfer even upon distribution is not available:

Transfer event: MUST trigger when tokens are transferred, including zero value transfers.

Ref: ethereum/EIPS/eip-20

With a superficial impact assessment it became clear that various tools will stop producing accurate results, including at least Dune and the Graph. Basically any aggregator, indexer, or offchain data processor that relays on accumulated events instead of calling token.balanceOf will not be able to:

discover all holders
compute the correct balance of withdraw recipients

See doc for more details on impact analysis Scope - HackMD

In the last Gnosis chain core dev calls, we agreed that the impact is high enough to go for a solution before the fork.

Proposed solution

Nethermind devs have researched ways to include the system transaction logs into the block, but all solutions introduce bigger problems (see this doc for a summary of considered options Gnosis system transaction - HackMD).

Instead, modifying the withdraw / deposit contract to perform the transfer step in a non-system transaction checks the goal of making the Transfer events available to consumers. This means implementing a pattern similar to DeFi protocols, where someone must initiate a claim transaction to disperse funds from a source contract.

For reference the smart contract changes to the deposit contract are linked here

github.com/gnosischain/deposit-contract

Implement Gnosis withdrawals pull

gnosischain:master ← gnosischain:withdrawals-pull

opened 06:23PM - 07 Jun 23 UTC

dapplion

+147 -397

Current master (via https://github.com/gnosischain/deposit-contract/pull/25) imp…lements push withdrawals. We originally decided to implement this strategy because: - Requires the least amount of actions from stakers, which get the withdraw tokens credited in their address by block processing - This behavior follows the UX in Ethereum, which is what stakers may expect here too However @filoozom noted that since the ERC20 transfer happens as part of receipt-less system transaction, the Transfer logs are not accessible anywhere. This breaks downstream tooling and will cause token balances to be incorrectly reported. Otherwise tooling is forced to incorporate custom logic to handle this differences, raising the cost of the feature. Due to this in the last core devs call consensus is formed that the incompatibility in tooling + the extra complexity does not justify going for the push strategy. This PR implements a pull strategy, which requires a final `claim` step to credit the withdrawn tokens to stakers. The `claim` happens in a regular transaction after the withdrawal block, so the Transfer receipts are available. Also, the insolvency case does not need to be handled explicitly, which significantly reduces the complexity of the contract to basically this two functions: https://github.com/gnosischain/deposit-contract/blob/2e2eea9b5f131132a518799289a89990f5dadd23/contracts/SBCDepositContract.sol#L249-L265 https://github.com/gnosischain/deposit-contract/blob/2e2eea9b5f131132a518799289a89990f5dadd23/contracts/SBCDepositContract.sol#L271-L277 Note that **anyone** can claim for any address. I expect Gnosis devops or other interested parties (staking services) to sponsor and auto-claim on behalf of stakers such that the perceived UX for the staker is the same as with the push approach

Why this post? Request for input

The UX of skaters will be subtlety but directly affected by this change:

someone will be required to call “claim” on the deposit contract after a withdraw has been processed for those funds to be usable by the withdrawee

Note that we expect interested parties (i.e. Gnosis devops) to sponsor claims on behalf stakers at a regular daily interval, such that no action should be required by stakers.

However, it’s important to make sure that this approach is okay with current and future Gnosis stakers, both solo stakers and staking protocols. If you are an affected party, please let us know:

Does the additional requirement of a claim transaction break your staking setup in anyway?
Do you have any concerns or risks introduced by this requirement?

What’s next

If we don’t find any issues of concern with this proposal, we only need to update the proposed update for the deposit contract. No changes are needed to execution or consensus clients. So once the new contract has been audited, we’ll run an extra shadow-fork test and then pick a date for Gnosis Shapella fork.