An onchain wallet interaction occurs when a transaction is processed under a blockchain network’s rules and its effects are recorded on that network. Wallet software or signing infrastructure can prepare and authorize an action, but it is the network—not the interface—that processes the transaction. Many wallet operations do not, by themselves, change blockchain state.

What makes a wallet interaction onchain?

“Onchain” describes activity handled by a blockchain and reflected in its records or state. A wallet interface may let someone prepare an action, review its details, or request authorization. Those interface steps alone are not necessarily onchain transactions: the action becomes an onchain interaction when a transaction is submitted and processed under the network’s rules.

The division matters because a wallet and a blockchain perform different jobs. Wallet software can present an action and coordinate signing, while network participants apply the relevant network rules. A specific wallet design may assign these tasks differently; the useful distinction is between preparing or authorizing an action and the blockchain processing it.

Some wallet activity is offchain. For example, opening an interface or changing a display preference does not, on its own, show that a blockchain transaction has occurred. Likewise, an application may maintain information outside the chain. Whether an action changes blockchain state depends on whether it reaches and is processed by the relevant network—not merely on whether the action appears in wallet software.

How an onchain wallet transaction reaches the network

A general transaction flow has four stages: construct the transaction data, authorize it, submit it through network infrastructure, and let the network process it. These stages may be handled by different components. One documented EVM developer-wallet flow, for example, separates wallet creation, transaction construction with a blockchain node, and transaction signing through a server-side SDK. That is a concrete implementation example, not a universal architecture.

Authorization commonly involves a signing mechanism. For an Ethereum externally owned account, a valid signature supports attribution of key control for that transaction. It does not, by itself, establish which human, organization, device, or service controlled the key. More generally, evidence that an action was signed should not be confused with proof of a person’s identity or with the network’s decision to process the transaction.

Signing and submission are distinct steps. A signed transaction may be passed to network infrastructure for submission; the signature alone is not the same thing as the transaction being recorded onchain. Network-specific rules determine whether a submitted transaction is accepted and how its effects are reflected in state. Transaction formats, validation rules, and the terms used for network processing can differ, so a single chain’s lifecycle should not be treated as universal.

Bridges illustrate why the relevant network matters. A bridge coordinates token, message, data, or contract-call activity between otherwise isolated blockchain environments. The destination chain changes only after its bridge-side logic accepts a cross-chain message or transfer condition. The activity may therefore involve more than one network, each with its own processing and records.

What the blockchain records—and what stays offchain

At a high level, a blockchain records activity that its network processes, such as accepted transactions and the resulting changes to network state. The precise record and the state affected depend on the chain and transaction. A wallet’s screens, local preferences, and other application-side information are not automatically part of that record merely because they are used to initiate or display an action.

Wallet software and supporting infrastructure can also exchange or organize information outside the blockchain. The boundary is not always visible in the interface: a screen may combine network data with wallet-side or service-side presentation. Seeing information in a wallet therefore does not, by itself, establish that the information was written to the chain. The relevant question is whether the network processed a transaction that records or changes state.

A recorded signature also has limits as evidence. For an Ethereum externally owned account, it can support the conclusion that the corresponding key authorized a transaction, but it does not identify the person or service behind that key. The onchain/offchain distinction is about where an action is processed and recorded, not a guarantee that a blockchain record reveals real-world identity.

Operational considerations when using onchain wallets

Builders and operators should distinguish transaction construction, signing, submission, and network processing in their workflows. Keeping those stages clear helps identify where an action is waiting or which component is responsible for it. It also prevents an interface from implying that signing alone means the blockchain has recorded the action.

Network compatibility matters. A transaction must be handled under the relevant network’s rules, and transaction formats and validation behavior are not identical across blockchains. If an interaction spans chains, bridge-side logic and the destination chain’s acceptance condition also matter. An application should avoid treating a submitted action on one network as proof that a separate network has changed state.

Fees and processing time are network- and condition-dependent. Because the allowed evidence here does not establish specific fee rules, timing, or finality for a named network, those details should be checked against current documentation for the chain and implementation involved. Avoid assuming that every network uses the same confirmation terms or that a particular transaction will be processed within a fixed period.

Finally, authorization and processing should not be described as a security guarantee. A valid signature may indicate key control for a transaction in the applicable account model, but it does not by itself establish the signer’s identity, validate the transaction’s intended effect, or prove that a network accepted it.

A practical test for whether an action is onchain

Ask: did this action cause a transaction to be processed under a blockchain’s rules, with a record or state effect on that network? If yes, it is an onchain interaction in that context. If it only changed a local display, an application setting, or an offchain service record, it is not thereby an onchain transaction.

For actions involving multiple networks, apply the test to each one. A bridge can coordinate activity between separate blockchain environments, but the destination chain changes only after its bridge-side logic accepts the relevant message or transfer condition. Do not collapse the source-chain action, bridge processing, and destination-chain effect into one undifferentiated event.

The central distinction is simple: a wallet can help prepare, authorize, or submit an interaction, while the blockchain records activity processed under that network’s rules. Whether a particular step is onchain depends on what the network actually processes—not on what the wallet interface calls it.

Sources and references