Modern Treasury has acquired Beam.Build for what's next →
Cryptographic immutability is a powerful tool for securing data, which requires encryption methods on each transaction to guarantee immutability. It’s often used for blockchains and distributed ledger systems to mitigate fraud.
Cryptographic immutability is a powerful tool for securing data, which requires encryption methods on each transaction to guarantee immutability. It’s often used for blockchains and distributed ledger systems to mitigate fraud.
But for high-throughput, centralized application ledgers, cryptographic immutability ultimately causes bottlenecks and slows down applications.
To understand cryptographic immutability, let’s look closer at its two core concepts:
- Immutability is a necessity for any ledger. It means that once data is written, it can’t be modified or deleted. Within a ledger system, this means you can only append data (called “append-only”), not delete it. Essentially, all changes require new entries, and nothing is ever overwritten.
- Cryptographic means using cryptographic algorithms to secure data, ensuring authenticity while preventing and detecting any attempts at tampering. Examples include:
- Hashing (e.g., ) produces a fixed-length “digital fingerprint” of your data.
- Digital signatures verify the authenticity of transactions within the ledger system.
Why Cryptographic Immutability Works for Distributed Ledgers
The clearest example of why cryptographic immutability works for distributed ledgers can be seen in blockchain transactions. Within the blockchain, every ledger is hashed, and each new entry references the previous hash. That means you can quickly tell if it’s been tampered with or if fraud occurs because it “breaks” the chain.
In distributed databases, cryptographic immutability enables different participants to verify that the system will maintain integrity and that any fraud will be apparent. And, since the blockchain prioritizes security, most users understand that there will be latency and are willing to accept the delays. The tradeoff of latency to guarantee protection against tampering is unrealistic for ledgers that require high throughput.
Why Cryptographic Immutability Doesn’t Work for Application Ledgers
The majority of major financial applications don’t operate as distributed systems and instead use a centralized ledger. Interestingly, many of Modern Treasury’s cryptocurrency or stablecoin customers also maintain a separate ledger outside of the blockchain. Doing this allows them to track transactions and maintain a single source of truth, whereas on the blockchain, the transaction history is distributed.
In a single ledger in which each written transaction requires hash computation in a growing chain, the verification process introduces Central Processing Unit (CPU) overhead. This is an approach that Amazon’s now depreciated Quantum Ledger Database used and caused several delays that a major brokerage customer described as “terrible.” The latency and low throughput simply equal poor customer service.
It’s necessary to remember that chained design limits parallelism, where transactions can happen concurrently. This can cause delays unsuitable for high-volume applications in which concurrency or speed matter.
Let’s look at how cryptographic immutability could affect latency in practice:
- A transaction is written to the ledger
- The system creates a hash that is stored with the data entry
- When retrieved, hashes are computed to verify integrity
If each new transaction depends on the previous transaction, and each transaction’s hash must be computed for verification, things start to fall apart. An API call that previously took milliseconds (e.g., expected balance on [a specific date]) suddenly takes several seconds because of computations. Those seconds add up when you’re processing thousands of transactions happening simultaneously.
Immutability Without Cryptography
Immutability without cryptography is a better design for high-throughput applications and centralized systems:
- Append-only writes, without transactions being overwritten, , or deleted
- Audit logs that allow historical data to be reconstructed whenever necessary
- ACID compliance, which ensures both consistency and durability
When deciding how to secure your ledger, weigh the tradeoffs: Do you need tamper resistance, or do you need practical throughput? Choosing the right process for your situation impacts speed, audits, and the customer experience.
Learn
Ledgers are foundational to any company that moves money at scale. Explore the accounting fundamentals behind the ledgering process, the differences between application ledgers and general ledgers, and more.
A chart of accounts (COA) is an index of all the different accounts within a company’s ledger.
A Ledger Database is a database that stores accounting data. More specifically, a ledger database can store the current and historical value of a company’s financial data.
Pessimistic locking and optimistic locking are types of concurrency controls designed to handle concurrent updates in a ledger system, helping prevent race conditions and maintain immutability in financial ledgers.
Learn the difference between Single-Entry Accounting and Double-Entry Accounting
Data immutability is the idea that information within a database cannot be deleted or changed. In immutable—or append-only—databases, data can only ever be added.
GAAP, or Generally Accepted Accounting Principles, is the US system for preparing financial statements. It lays out the rules for how companies measure, present, and disclose their financial performance. The goal is to make reports reliable and easy to compare across businesses.
ACID stands for Atomicity, Consistency, Isolation, and Durability—the four rules that keep database transactions running smoothly. Together, they ensure every transaction is reliable, predictable, accurate, and intact.
Every Account in a double-entry ledger is categorized as debit normal or credit normal. Debit-Normal Accounts represent uses of funds (assets, expenses); Credit-Normal Accounts represent sources of funds (liabilities, equity, revenue).
Balance caching means storing the latest known account balance outside the core ledger for faster reads.
In the context of software, concurrency control is the ability for different parts of a program or algorithm to complete simultaneously without conflict. Concurrency controls in a database ensure that simultaneous transactions will be parsed appropriately.
Cryptographic immutability is a powerful tool for securing data, which requires encryption methods on each transaction to guarantee immutability. It’s often used for blockchains and distributed ledger systems to mitigate fraud.
An API call is idempotent if it has the same result, regardless of how many times it is applied. Inadvertent duplicate API calls can cause unintended consequences for a business, idempotency helps provide protection against that.
Sharding means dividing your database into horizontal partitions, called shards, which can each store a subset of data. to reduce latency; this often happens when data scales. Within a ledger, sharding is used to split transactions or accounts so that each shard holds a portion of the total ledger.
A digital wallet (also sometimes called an electronic wallet) is an application that securely stores digital payment information and password data for a user.
A ledger API allows companies who need to move money at scale quickly and easily access, track, audit, and unify all of their financial data in one place.
The ledger balance, also called the current balance, is the opening amount of money in any checking account every morning. The ledger balance should remain the same for the duration of the day.
A ledger (also called a general ledger, accounting ledger, or financial ledger) is a record-keeping system for a company’s financial transaction data.
A subsidiary ledger is used to keep track of the details for a specific control account within a company’s general ledger.