Documentation

Verify input data on External Decoder

For EVM Chains only

Suggest Edits

Input Data (also known as calldata) refers to the data payload sent along with a transaction, specifically when interacting with smart contracts.

Understanding Input Data

For multisig safe transactions through Liminal Web application the input data contains 10 parameters (0-9) and for Mobile MPC transactions the input data contains 2 parameters.

  1. to: This is the destination address for the transaction. If you’re transferring a token, the address would be the token contract address. For native coin transactions (like Ether), this would be the recipient's wallet address.
    Example:
    • For token transfer: to: "0xTokenContractAddress"
    • For native coin transfer: to: "0xRecipientAddress"
  2. value: The amount of ether (native coin) in the transaction (0 for token transfers). This is the amount of Ether or native coin being transferred in the transaction. For token transfers like USDC, this value is set to 0 since the transfer is handled by the token contract itself.
    Example:
    • For a native coin transfer: value: 10 (meaning 10 Ether is sent).
    • For token transfer: value: 0.
  3. data: This field contains the encoded input data for the transaction. For a token transfer, this will be the function call encoded in a way that the contract understands. For native coin transactions, this is usually 0x since there’s no additional data (the amount is already specified in value).
    Example:
    For a token transfer: data: "0xa9059cbb00000000000000000000000051c29314e3275b49213675a466819ed6d81244e00000000000000000000000000000000000000000000000000000000001312d00"

In the above example the meaning of this data can be understood as below

0xa9059cbb - Hex Value for transfer function
00000000000000000000000051c29314e3275b49213675a466819ed6d81244e - 32 byte Desitnation address after removing "0x"
00000000000000000000000000000000000000000000000000000000001312d00 - 32 byte hex value for transfer amount

For native coin: data: "0x"

  1. Operation: This represents the type of operation being performed.
  • Call: Identified by an operation value of 0. This is the most common transaction type for Gnosis Safe. It represents a transaction that triggers a function on an external contract, such as a token transfer or interaction with a DeFi protocol. The Safe contract serves as the sender in these transactions.
  • DelegateCall: Identified by an operation value of 1. In this type of transaction, the Safe contract delegates execution to another contract. However, any state changes are applied to the Safe contract itself. This is typically used for interactions with Safe contract modules or extensions.
  • Create: Identified by an operation value of 2. This type of Safe transaction deploys a new contract on behalf of the Safe. The to address is usually empty, and the data field contains the bytecode of the new contract.
    ⚠️Note: Ensure that the operation value is always 0. Any change in the operation value, other than 0, must be reported to Liminal immediately, and no further action should be taken without consultation.
  1. SafeTxGas BaseGas GasPrice:
    We typically pass safeTxGas, baseGas, and gasPrice as 0 in Gnosis Safe transactions because we want the Gnosis Safe relayer or execution logic to auto-estimates gas
  • safeTxGas = 0 → Gnosis Safe contract estimates how much gas is needed to execute the transaction payload.
  • baseGas = 0 → No fixed overhead is added to the total gas (or it's handled off-chain).
  • gasPrice = 0 → You're not reimbursing anyone for gas, i.e., the signer or relayer is sponsoring the fee.
  1. refundReceiver: This parameter specifies an address that will receive any leftover ETH after the Safe transaction is executed and the actual gas cost is deducted. If its value is set to the zero address (0x0000000000000000000000000000000000000000), any remaining ETH will stay in the Safe contract itself.
  2. signatures: This field contains the signatures from the required addresses to autorise the transfer. The data field encodes the token transfer function, specifying the recipient address and the token amount. The signatures field indicates which addresses are needed to approve the transaction.

By default, Liminal shows the decoded input data so you can easily verify the transaction details. However, for security reasons you may want to additionally verify the raw input data in an external decoder by copying the raw data with the copy button, clicking on 'Verify on Decoder' and pasting it in the safe transaction decoder as shown in the below steps

Vaults Desktop / Web

  1. Click on the Raw Data button
  1. Copy the raw data via the copy button and click on Verify on Decoder
  1. Paste the raw data and click on decode transaction

Vaults Mobile

  1. Click on Raw Data
  1. Select the Data, Copy it and Click on Verify on Decoder.

For mobile, you could also use Etherscan's offical input data decoder since the current website is not mobile friendly.

  1. Copy the input data
  2. Select without ABI
  3. Paste the input data

Updated 1 day ago