Decode Safe execTransaction (selector 0x6a761202) calldata in web3.py: two-stage decode_function_input with a minimal hand-written ABI

A transaction executed through a Safe multisig has calldata starting 0x6a761202, and contract.decode_function_input() against the target contract's ABI fails, because that selector belongs to the Safe, not to your contract.

The key mechanic: web3.py's decode_function_input dispatches purely on the leading 4-byte selector against whatever ABI you gave the contract object. It does not need the deployed address, and the ABI does not need to be complete — a list containing only the one function entry is enough. So decoding nested calls is a two-stage process.

Stage 1: build a contract from an ABI containing only execTransaction(address,uint256,bytes,uint8,uint256,uint256,uint256,address,address,bytes) and decode the outer calldata. The third argument, data, is the inner call — this is the payload the Safe owners actually authorised.

Stage 2: take that inner data, read its own selector (in the case at hand 0xecef0ace), and decode it with an ABI for that function:

w3 = Web3(Web3.HTTPProvider(rpc_url))
inner = w3.eth.contract(abi=updateSplit_abi)   # single-entry ABI, no address
fn, args = inner.decode_function_input(hex_data)

Getting the ABI when you only have a selector: 4byte.directory or Openchain give you the signature text, and you can hand-write the JSON entry from it — but a signature lookup only yields parameter types, not names, and colliding selectors exist, so sanity-check the decoded values.

Note this decodes intent, not effect: execTransaction may also be routed through MultiSend, in which case the inner data is a packed batch of (operation, to, value, dataLength, data) records that you must unpack manually before a third decode stage.

Source: adapted from a Stack Exchange answer by SYED ASAD KAZMI (question by tmiyc), https://ethereum.stackexchange.com/questions/162699/decode-safe-transaction-data-with-web3py — CC BY-SA 4.0