# Gnosis system transaction

## System transaction use

Gnosis (former xDAI) uses a system transactions as part of block processing to:
- mint native token in response of native bridge deposits (live since genesis)
- distribute stake token withdrawals from beacon chain (planned for Shapella fork)

## System transaction specs

The current spec for a system transaction specifies this set of rules (ref [gnosischain/specs](https://github.com/gnosischain/specs/blob/master/execution/withdrawals.md#specification)):
- Gas limit checks are disabled compared to block.gas_limit - block.gas_used (ref).
- Caller balance and nonce checks are disabled. Nonce for system address is not incremented (ref_1, ref_2).
- Fees are not added (ref)
- block.gas_used is not incremented (ref)
- If the transaction reverts, or runs out of the gas, the entire block MUST be considered invalid.

Plus, no receipt nor transaction exist in the block for the transaction. Only the resulting state change of its execution is part of the block's post state.

## ERC20 non-spec

The withdrawals system transaction involves changing the state of an ERC20 token contract. Specifically transfers tokens from the deposit contract to the withdrawal recipient. There is no `Transfer` in the block's receipts acknowleging that transaction.

## Option A: current spec

Logs of system transaction are not in the block, nor exposed.

- **Pros**: Does not need more spec modifications, so no more different rules in block handling respective to Ethereum
- **Cons**: Unable to access logs in any way

## Option B: add system transaction receipt to receipts - no tx

- **Pros**: Logs available as tooling expects. Block structure remains unchanged.
- **Cons**: receipts count != txs count. This _may_ break some tooling (unconfirmed). Changes in block production, may complicate MEV integration.

## Option C: system transaction receipt and tx

- **Pros**: Logs available as tooling expects. Block structure remains unchanged.
- **Cons**: Having a "fake" transaction in the block adds significant complications that require custom handling. Changes in block production, may complicate MEV integration.

## Option D: virtual logs on JSON RPC only

- **Pros**: Does not require changes in consensus, block production or block processing.
- **Cons**: Ugly hack, information exists in eth_getLogs but not in the block, may break assumptions of tooling. May not fix original issue for tools that obtain logs from receipts.

## Option E: separate system transaction receipt

Don't add system receipt to normal receipts but rather have new dedicated methods for it, e.g. eth_getSystemLogs. Perhaps replace ommersHash with systemReceiptHash in block header.

- **Pros**: No changes to existing invariants/assumptions
- **Cons**: Tools have to use the new methods. Block structure meaning differs from Ethereum and can conflict with future field use

## Option F: withdraw contract, pull distribution

The issue stems from deposit contract "push"ing tokens to users as part of block processing. Instead, as part of block processing just store in contract storage withdrawable balances. Then expect some account to trigger distribution with a regular transaction.

- **Pros**: No changes on consensus. May aleviate onchain load as it batches transfers. Index count >> withdraw credentials count. No need to handle insolvency case, simpler system transaction. May delay a taxable event in
- **Cons**: Worse UX for users, requires an extra step to get tokens

## Impact study

**Explorers**

- **Etherscan**: TODO
- **Beaconcha.in**: TODO
- **Blockscout**: TODO

**Indexers**

- **The Graph**: TODO
- **Dune**: TODO