What a transaction input references, precisely
A transaction input references a previous output, not a wallet or a balance. On a UTXO chain the reference is an outpoint: the 32-byte transaction hash plus the 4-byte output index, usually written txid:vout. The distinction becomes practical when you compare that model with an account-chain swap like
.
The outpoint is the reference
Bitcoin-style accounting keeps spendable value in unspent transaction outputs, or UTXOs. A transaction input names one of those outputs as the thing it wants to spend. The name is an outpoint: the txid of the transaction that created the output, and the vout, the output's zero-based position in that transaction's output list.
An outpoint is not an address. It is not a balance. It is a pointer to a specific entry in a specific transaction. That is why the input does not carry an amount. The amount sits in the referenced output. The input's job is to unlock that output by satisfying the script or witness condition attached to it.
This also gives the model its double-spend rule. A referenced output can be spent once. If a later transaction tries to reference the same outpoint, that input is invalid because the output is no longer in the UTXO set. Two transactions spending the same outpoint cannot both be confirmed.
Account chains use calldata, not outpoints
Ethereum and most EVM chains do not maintain UTXOs. An account has a balance in state, and contracts hold balances in storage. A transaction still has an input field, but it is not a pointer to a previous output. That field is calldata: a function selector plus encoded arguments. The transaction says which contract to call, what native value to send, and what function to execute.
A swap transaction on an AMM is the clearest example. The calldata references the token addresses in the swap path, the exact amount of token being sold, the minimum amount to receive, and the recipient. The router reads the sender's token balance from the ERC-20 contract's storage and moves tokens according to the pool's reserves. No outpoint is being spent. The result is a set of balance changes, not a collection of new outputs.
What you need before you start
If you are building a UTXO transaction, you start with a list of confirmed, unspent outputs that your keys can unlock. You do not start with "my balance" as a single number. Each input references one outpoint, and each referenced output must have a matching unlocking script or witness.
If you are building a swap on an EVM AMM, you need an approved token allowance and the router's expected parameter layout. The calldata has to encode the exact path and amounts. A wallet that supports both models is doing two different jobs: one looks up outpoints, the other encodes calldata.
What you end up with is different too. A UTXO transaction completes as a set of new outputs, spendable boxes that did not exist before. A swap completes as a set of balance changes: the sender's token balance goes down, the recipient's goes up, and the pool's reserves shift. There are no new spendable boxes, only updates to existing storage.
When the distinction decides things
Indexers and explorers: a UTXO indexer tracks outpoints and their spend status; an EVM indexer tracks storage slots and events. Searching for "inputs" in the wrong model gives you the wrong answer.
Signing and fees: a UTXO signer must know the referenced outputs' values to compute the fee; an EVM signer must know the calldata and current gas price, not earlier transaction outputs.
Portfolio tools: a UTXO wallet lists inputs as outpoints. A swap tool lists the input token amount. Both use the word "input," but one is a reference to prior state and the other is an argument in a contract call.
If you are reading an account-chain transaction, outpoint language does not apply. There is no txid:vout to unlock. There is a to field, a value field, and calldata, and the "input" shown by block explorers is that calldata, not a reference to an earlier output.
So what a transaction input references depends on the ledger. On a UTXO chain it references a prior output and nothing else. On an account chain it references a function and its encoded arguments. The precise answer is not a balance; it is a pointer, and the pointer's shape tells you which ledger model you are dealing with.