SuperEx - superex.me

[superextimmy]

SuperEx Educational Series: Understanding What Exactly Does an On-Chain Transaction Contain?

 

#SuperEx #EducationalSeries #OnChain

An on-chain transaction looks simple on the surface: how much was sent, where it went, whether it succeeded, and how much fee was paid. But what a wallet shows is only a human-friendly summary. 

The real transaction contains a full set of fields and rules, more like a compressed instruction sheet.

So an on-chain transaction is not just a payment record. More accurately, it is a signed request to change blockchain state. It can be a transfer, approval, contract call, contract deployment, NFT mint, staking action, swap, vote, or even a cross-chain message trigger.

Concept Introduction 

In Ethereum, a transaction is a cryptographically signed instruction from an account, used to update network state. A simple ETH transfer is a transaction, and so is a smart contract call. The first mainly changes account balances; the second may execute contract code and change contract state.

An Ethereum transaction usually contains sender, recipient, nonce, value, input data, gas limit, fee parameters, chain ID, and signature. Different transaction types add different fields. For example, EIP-1559 transactions include maximum fee and priority fee parameters

In Bitcoin, the structure is different. Bitcoin does not use an account balance table. It uses the UTXO model. A transaction contains inputs and outputs: inputs spend previous unspent outputs, and outputs create new spendable records. The fee is the difference between total inputs and total outputs.

What Does an Ethereum Transaction Contain? 

The first part is the recipient address.

• If the recipient is a normal account, the transaction usually transfers ETH. 
• If the recipient is a contract address, the transaction triggers contract code. 
• If the transaction deploys a new contract, the recipient may be empty and the contract code is placed in the input data.

The second part is value, meaning the amount of native asset sent with the transaction.

On Ethereum, value means ETH, usually denominated in wei. This is easy to misunderstand: in ERC-20 token transfers, value is often 0 because the user is calling a token contract, not directly sending ETH.

The third part is nonce, the transaction sequence number of the account.

It defines the order of transactions from the same account and helps prevent replay. Without nonce, old transactions could be reused in dangerous ways.

The fourth part is gas settings.

Gas limit defines the maximum computation the transaction may consume. Fee parameters define how much the user is willing to pay per unit of gas. After EIP-1559, common fee fields include maximum fee and priority fee. The base fee is set by the protocol and burned, while the priority fee incentivizes block producers.

The fifth part is input data.

This is where many transactions carry their real instructions. When you click Swap, Approve, or Mint in a DApp, the function and parameters are usually encoded in input data. It may look like a long hexadecimal string, but the contract knows how to interpret it.

The sixth part is the signature.

The signature proves that the transaction was authorized by the private-key holder. The chain does not believe a user simply because they say, “I am Alice.” It verifies cryptographic authorization.

Bitcoin Is Built Differently 

A Bitcoin transaction is more like spending old notes and creating new notes.

It contains version, inputs, outputs, locktime, and related data. Inputs reference specific outputs from previous transactions, meaning: “I am spending this earlier received output.” Outputs define new amounts and spending conditions, determining who can spend them later.

Users see “send BTC to an address,” but underneath, Bitcoin is not adding and subtracting account balances. It consumes UTXOs and creates new UTXOs. A wallet balance is the sum of spendable UTXOs controlled by the user.

What Is Not Inside the Transaction? 

First, the transaction itself does not necessarily contain the success result. What you sign and broadcast is a request, not the result. Success depends on whether it is included in a block, executed correctly, updates state, and receives enough confirmations.

Second, the transaction itself does not contain confirmation count. Confirmations come from later blocks. They are not included as a field when the transaction is created. Inclusion and finality are different things.

Third, the transaction itself does not contain a full balance table. Ethereum balances come from account and contract state. Bitcoin balances come from the UTXO set. Transactions change state, but they are not full balance sheets.

Fourth, the transaction should never contain the private key. The private key is used to sign, not to be included. If anyone asks you to enter your private key into a page, message, or transaction field, that is not an on-chain operation. That is a security disaster.

A Simple Case 

Suppose Alice clicks “Send 100 USDT to Bob” in a DApp.

The recipient of the transaction may not be Bob’s address. It may be the USDT contract address. The value may be 0 because no ETH is being sent directly. The real transfer instruction is inside input data: call the transfer function and send the token amount to Bob.

The transaction also contains Alice’s nonce, gas limit, fee parameters, chain ID, and signature. Nodes check the signature, balance, nonce, and fee settings. Once included in a block, the EVM executes the USDT contract and updates contract state: Alice’s token balance decreases, and Bob’s increases.

The user sees “transfer successful,” but the chain processes authorization, contract execution, state change, event logs, and block confirmation. The front end looks simple, while the protocol does the heavy lifting.

Common Misunderstandings 

First misunderstanding: every transaction directly lists the final recipient and amount.Not always. In contract transactions, the real recipient and amount may be encoded in input data. Token transfers often work this way.

Second misunderstanding: the transaction hash is filled in by the user.No. The transaction hash is calculated from transaction data. It is an identifier, not a user-chosen name.

Third misunderstanding: the fee is simply part of the transfer amount.On Ethereum, fees are determined by gas usage and fee settings, separate from value. On Bitcoin, fees come from the difference between total inputs and total outputs.

Fourth misunderstanding: wallet display text equals the full transaction content.A wallet translates transaction data for users. If the translation is unclear, a user may only see a “Confirm” button without understanding what they are authorizing.

Risks and Design Questions 

The first risk is blind signing.Much input data looks unreadable to ordinary users. If a wallet cannot clearly explain the transaction intent, users may sign without understanding the action.

The second risk is approval risk.Approval transactions may not transfer assets immediately, but they can allow a contract to spend tokens later. Many incidents begin not with direct transfers, but with ordinary-looking approvals.

The third issue is nonce management.Transaction ordering from the same account depends on nonce. Wallet features such as “speed up” and “cancel” often work through nonce replacement. Without understanding this, users may feel the wallet is doing something mysterious.

The fourth issue is replay risk.In a multi-chain environment, signatures need to be bound to chain ID, application domain, or specific context. Mature transaction design must make authorization boundaries clear.

Conclusion

An on-chain transaction contains a set of verifiable machine-readable instructions: target address, value, nonce, fee settings, input data, chain ID, signature, and, depending on the blockchain model, inputs, outputs, scripts, locktime, and related structures.

Ethereum transactions are state-change requests from accounts. Bitcoin transactions consume old UTXOs and create new ones. The structures differ, but the logic is similar: who authorized it, what is being spent, who receives it, under which rules, and whether nodes can verify it.

In plain English: you click one button in a wallet, but the chain receives a serious instruction package. The wallet translates it for humans, and nodes verify it for the network.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

Click to register SuperEx
Click to download the SuperEx APP
Click to enter SuperEx CMC
Click to enter SuperEx DAO Academy — Space