Cryptocurrency Ledger Entries and How Nodes Propagate Them

How Cryptocurrency Ledger Records Transactions starts with a hardware signer that generates and keeps private keys on a secure element chip. The device never exposes those keys to a computer or phone. Instead, the companion desktop or mobile application prepares an unsigned transfer, sends it to the signer, and the signer displays the recipient address, amount, and network fee on its own screen. You confirm physically. The signer then produces a cryptographic signature. The signed payload goes back to the companion, which broadcasts it to nodes. The distributed register updates only after network consensus. The hardware signer does not store a copy of that register.

The companion app fetches account balances and operation history from blockchain data providers. It caches that information locally for display. The authoritative copy remains the public distributed register maintained by nodes. If the companion shows a pending transfer, that status comes from a node or indexer, not from the device. You can verify the final state by checking the same address in any independent block explorer or node. The device itself only proves that a specific key holder authorized a specific payload.

Every transfer requires two separate checks: the device screen shows what the key will sign, and the companion shows the network’s response. A malicious computer can alter the unsigned payload before it reaches the signer. The signer’s screen prevents that by showing the actual destination and amount. A compromised companion can lie about balances or pending status, but it cannot forge a signature without the private key. For that reason, always compare the address on the signer’s screen with the intended recipient. Never type a seed phrase into any computer or phone.

Backup and restore follow the same separation. The seed phrase, generated on the device, is the only way to restore keys on a replacement signer. The companion app does not hold that phrase. Firmware updates are prepared by the companion but installed only after physical confirmation on the device. If a support agent, pop-up, or chat asks for the 24 words, it is a scam. Official help lives on the manufacturer’s support site. The device’s secure element resists physical extraction, but no setup removes the need to protect the backup.

What Data Gets Written into a Blockchain Transaction Record

Verify every field shown on the hardware wallet screen before approval: recipient address, amount, and network fee. If the companion app and device display differ, reject the signature. The device is the final checkpoint because its secure element never exposes the private key.

Fields Inside an Account-Based Entry

For account-based chains, the signed payload typically contains sender address, recipient address, value, nonce, gas limit, gas price or fee parameters, chain ID, and an optional data field. Ethereum-style entries add access lists or base-fee and priority-fee parameters, while other designs use sequence numbers and expiration windows. The signature itself–r, s, and v values–is appended after the device signs the hash of these fields.

The companion app constructs the unsigned payload, then asks the device to parse and display it. The secure element inside the device signs that payload without sending the private key to the host. After signing, the signed blob is broadcast to peers. Validators or miners check the signature against the sender’s public address, then include the entry in a block. The block header stores a Merkle root that commits to all included entries, and the entry’s identifier is usually a hash of its serialized bytes. Changing any field alters that hash, so the signature becomes invalid.

Your seed phrase, PIN, and private key are never written into the public blockchain archive. Only public addresses, signatures, amounts, and routing metadata become visible.

Fields Inside a UTXO Spend

For UTXO chains, the entry references previous outputs by prior output hash and index, then creates new outputs with locking scripts and values. It may include a locktime, sequence numbers, and witness data for segregated witness spends. The device screen shows the recipient and amount, but it may not decode every script or data payload; the companion app can display extra details when it recognizes the format.

Timestamps are not part of the signed payload itself; time comes from the block that confirms the entry. Some chains allow arbitrary bytes in an input data field or an OP_RETURN output, which can carry messages or commitments. When using the companion app, the app prepares the spend, the device confirms the critical fields, and the signed result is broadcast. If the device screen does not match the app’s recipient or amount, cancel. For high-value transfers, verify the address on the device, check the fee, and later inspect the final identifier in a block explorer. The chain, not the companion app, is the authoritative source for confirmation.

A signed entry cannot be edited after broadcast. To revoke a pending spend, you would need to replace it with a higher-fee conflicting entry, which many chains do not guarantee. Always confirm the device display before approving.

How Public and Private Keys Authorize a Ledger Entry

Approve each outgoing transfer only after the hardware wallet’s own screen shows the exact destination address, amount, and network fee.

A public key acts as a verifiable address generator: the companion app derives an address from it, shares that address freely, and uses the matching private key only inside the secure element to produce a signature for the unsigned payload prepared by the app.

The private key never leaves the device’s secure chip; it signs a hash of the transfer details, and any change to the destination, amount, fee, or nonce changes that hash and invalidates the signature. Network nodes check the signature against the public key, so a valid authorization proves control of the private key without revealing it. If the companion app is compromised, an attacker can alter the payload before signing, which is why the device screen must be read before physical approval.

Key element	Stored in	Authorizes	Shareable?	Exposure effect
Public key / derived address	Derived by the companion app from device-held material; the address can be shared	Lets peers check signatures and route funds to a controlled address	Yes, share the address to receive funds	No signing power; privacy loss if linked to identity
Private key	Secure element inside the hardware wallet; never exported	Produces signatures for outgoing transfers	Never	Full control of associated funds; immediate risk
Signature	Generated on the device for one payload	Proves approval of the exact destination, amount, fee, and nonce	Yes, as public proof attached to the transfer	Reuse or an altered payload fails node checks
Device screen check	Hardware wallet display during approval	Confirms what the private key will sign	No	Skipping it lets malware swap the address or amount

Use the companion app to build the unsigned transfer, connect the hardware wallet, inspect every field on the device display, and approve only when the displayed destination and amount match the intended movement; reject the request if the screen shows a different address, an unexpected fee, or a contract call you did not initiate.

Back up the recovery phrase offline and never type it into the companion app, a browser, or a support chat; the phrase restores the private key, so anyone who obtains it can sign entries without the device.

A signature alone does not move funds: nodes also check that the public key’s derived address has sufficient balance and that the signed message matches the network’s rules, while the device’s PIN and physical approval block remote signing even if the companion app is running on an infected computer.

Test with a small transfer before large movements, compare the first and last characters of the destination on both screens, and keep firmware current through the official companion app release channel.

How Nodes Validate and Propagate Unconfirmed Transactions

Verify the recipient address and amount on the hardware wallet screen before the companion app broadcasts a signed transfer.

Full nodes validate the signed payload before relaying it. They check the digital signature against the public key, enforce the account nonce or unspent output reference, reject double spends, apply script and consensus rules, and compare the offered fee rate with local relay thresholds. A node that disagrees drops the item, so the companion app may show a pending state while the wider network ignores it.

• Signature validity: confirm the signature matches the payload and the claimed key.
• State validity: check nonce order or unspent output availability against the current chain view.
• Policy filters: minimum relay fee, standard script type, size limits, and replacement rules decide whether the item stays in the pool.

Accepted items enter a memory pool, where fee rate, size, and dependency chains decide priority.

Propagation uses peer-to-peer gossip: a node sends inventory messages, peers request missing data, and the item spreads toward block producers. Compact block relay and pool synchronization reduce bandwidth.

Broadcast failure? Check connectivity, node sync, and official support.

Low-fee entries can be evicted, delayed, or replaced when replacement rules allow, and child-pays-for-parent can lift a dependent payment. Self-custody verification limits trust: the device screen remains the final checkpoint, while running a full node gives independent validation and better privacy than public endpoints. Lightweight setups rely on remote nodes for relay and pool status, so treat those endpoints as untrusted relays and never expose the recovery phrase. If an item stalls, verify the fee rate, inspect pool status through a trusted node, and rebroadcast only after the signed payload matches the device display.

How Blocks Group Transactions and Link to Previous Ledger States

Treat each block as a sealed batch of asset movements plus a pointer to the prior batch.

A block header commits to an ordered set of entries via a Merkle root: each entry is hashed, paired hashes are combined, and the final root goes into the header. Any change to an entry alters that root, so the header no longer matches the batch.

The header also carries the hash of the preceding block. That field links the new state to the earlier one; a node can walk backward from the latest header to genesis and verify that no prior header was swapped. Because the link is cryptographic, an attacker must redo every later header, not just an altered entry.

When you send coins from a hardware wallet, the companion app builds the unsigned operation, the device shows recipient and amount, and your physical approval produces a signature. The app broadcasts that signed operation to peers; block producers place it into a candidate batch, order it with others, and update the account state once the block is accepted.

Pending operations wait in a mempool. Block builders choose which ones to include, often prioritizing those with higher fees, then arrange them in a deterministic order. Reordering changes the Merkle root, so separate blocks cannot contain the same operations in different sequences and still produce identical headers.

Verify inclusion yourself: ask a full node for the block header and the Merkle branch for your operation, hash the branch upward, and compare the result to the root in the header. Then check that header’s predecessor hash against the previous header. This proves the operation sits in a specific block and that the block belongs to the chain your device signed for.

For a hardware signer, the practical rule is simple: confirm the destination and amount on the device screen, because that screen is the last trusted display before the signed operation leaves your control.

Chain reorganizations happen when competing blocks arrive. A node follows the branch with the most accumulated proof, discarding blocks that lose. Your companion app may show a balance from a block that later becomes stale; after the network settles on a longer branch, the app recalculates the account state from the winning chain. If the device signed an operation that is dropped, the signed payload can often be rebroadcast, but only if the same inputs remain unspent. Never approve a replacement operation on the device unless the companion app clearly shows the original is no longer viable.

How Consensus Rules Decide Which Ledger Version Is Accepted

Nodes, not the hardware signer, choose the accepted state of the distributed account book.

The device signs only payloads the user confirms on its screen; peers accept them only if balance, signature, and block-validity checks pass.

• Proof-of-work: accumulated work selects the heaviest valid branch.
• Proof-of-stake: justified checkpoints and finality votes settle the canonical tip.
• Permissioned or hybrid systems: validator quorums attest to one history.
• Rollups or sidechains: a parent chain or bridge contract defines the accepted state.

Consensus rules set the fork-choice function; the companion app queries one or more nodes and displays the branch those nodes follow, while the signer keeps keys inside its secure element, shows destination and amount, and cannot make an invalid spend valid. When two valid histories compete, the app may show one tip until the network converges; do not confirm a transfer whose details do not match the screen. Rule-changing forks require node upgrades, replay protection, or explicit user action, and device firmware only parses chain parameters it was built to support.

Verification is symmetric: every full node re-executes the relevant rules, rejects a bad signature or double spend, and gossips only the surviving tip. The device acts as signer and display, not as judge of global consensus.

To decide which version wins, check the node software’s fork-choice rule, inspect confirmations or finality signals, and compare block height and state root from independent nodes. If the companion app shows a different tip than a public explorer or a second node, wait for convergence before moving value. A hardware signer adds a physical confirmation step: verify the address and amount on its screen, because malware on a computer can alter the app’s display. Consensus does not protect against signing a malicious destination; it ensures validly signed spends are ordered consistently across honest participants. Keep firmware and companion software current through official channels, and treat a sudden chain split as a reason to pause, not as an invitation to sign.

Q&A:

If I send Bitcoin to someone, what actually gets written to the blockchain ledger?

A Bitcoin transaction does not write a new account balance. It lists inputs and outputs. An input points to coins from earlier transactions that the sender controls. The sender signs a message with the private key for those coins. That signed transaction is broadcast to nodes. Nodes check the signature, format, and whether the coins are unspent. If it passes, it waits in a mempool. A miner later includes it in a block. The block contains many transactions plus a header with a timestamp, a hash of the prior block, and a solution to the proof-of-work puzzle. Once nodes accept the block, the ledger now shows those coins as spent and creates new outputs tied to the recipient’s address. The recipient can spend them in a future transaction.

Who updates the cryptocurrency ledger, and how do different computers agree on the same history?

There is no single company or server that updates the ledger. Many independent nodes keep their own copy. Agreement depends on the network’s consensus rules. In Bitcoin, miners compete to add the next block by solving a proof-of-work puzzle. When one miner finds a valid block, it sends that block to other nodes. Each node checks the block’s transactions and its proof. If the block follows the rules, the node adds it to its copy. If two miners find blocks at nearly the same time, nodes may briefly hold different tips of the chain. The network then follows the chain with the most accumulated proof-of-work. Other cryptocurrencies use proof-of-stake or other methods. In proof-of-stake, validators are chosen to propose and confirm blocks based on the amount of coins they have locked, often with random selection and penalties for bad behavior. The shared rule set makes separate computers converge on one ledger, without a central authority.

Can someone change an old transaction in the ledger? What stops that from happening?

Changing an old transaction is extremely difficult because each block locks in the data of the block before it. A block header includes the hash of the earlier block. If someone alters one transaction in an old block, that block’s hash changes. That change breaks the link to every later block. To make the altered chain valid, the attacker would need to redo the proof-of-work for that block and all blocks after it, then catch up to the honest chain and convince most nodes to accept the new version. On large proof-of-work networks, this requires more computing power than most attackers can obtain. Proof-of-stake networks use different checks, such as validator voting and slashing, to make history revisions costly. Small networks or chains with weak validators can be attacked, so the level of protection varies. In normal use, a confirmed transaction stays in the ledger.

What is the difference between a public crypto ledger and a private one?

A public ledger is open. Anyone can download it, read every transaction, and often help validate new blocks. Bitcoin and Ethereum are examples. A private or permissioned ledger limits who can read it and who can write to it. A company or consortium may run the nodes and approve validators. Private ledgers can process transactions faster and hide business data from the public. They also rely on a smaller set of trusted parties. That trade-off means they offer less censorship resistance and less open verification than a public chain. Some projects use a mix: public settlement with private data channels, or sidechains that anchor to a public chain.

After a transaction is confirmed, can it be reversed or removed?

On most public blockchains, a confirmed transaction cannot be reversed by a user or a central operator. If you send coins to the wrong address, the ledger still records that transfer. Only the person who controls the receiving address could send the coins back. There are a few exceptions. A chain reorganization can remove a recent block if the network switches to a longer or heavier chain, so very new confirmations are less final than older ones. Exchanges may reverse an internal transfer if the coins never left their system, but that is not a change to the public ledger. Smart contracts can include functions that move or freeze assets, but those actions follow the contract code and create new ledger entries. For practical purposes, treat a confirmed on-chain payment as final.