Lot selection is often treated like a setting.
FIFO. HIFO. LIFO. Highest basis. Long-term first. A default gets selected, transactions flow through the system, and a realized gain or loss number comes out the other side.
That workflow may look clean because it produces an answer.
But for digital asset treasury teams, the default is not neutral. It is a tax and accounting decision. It determines which acquisition history is attached to a disposal, which basis is consumed, which holding period matters, which remaining lots are still available, and which outcome the organization may later need to defend.
If the team cannot explain why a lot was used, the reported number is weaker than it looks.
That is why Bedrock treats lot selection as governed financial policy, not a hidden calculation preference.
The Same Transaction Can Produce Different Outcomes
Consider a simple example: a company sells 1 BTC.
On the surface, the transaction is straightforward. One asset. One quantity. One sale price.
The tax and reporting outcome depends on which BTC was sold.
Was it an older lot with low basis and long-term holding-period treatment? A newer lot with higher basis? A lot connected to a treasury strategy? A lot sitting in cold storage? A lot already locked, assigned, or expected to support another workflow?
The market transaction may be identical, but the financial result can change materially depending on the lot selected.
That is the point many systems hide. They make the sale look like the event that creates the result. In practice, the sale plus the selected lot creates the result.
For finance and tax teams, that distinction matters. The question is not only "what did we sell?" It is "which units did we sell, why those units, and can we prove that decision later?"
FIFO Is a Fallback, Not a Strategy
FIFO has a role. It can be a useful fallback when no specific policy, standing instruction, or transaction-specific selection applies.
But FIFO should not become the organization's tax strategy by accident.
When digital asset activity is small, a simple default may be good enough. When holdings become material, the default starts carrying more weight. The organization may have lots with different acquisition dates, cost bases, holding periods, custody locations, restrictions, planning objectives, and review considerations.
At that point, "the system used FIFO" is not much of an explanation.
A better operating model starts before the disposal. The team should know which lots are available, which lots are protected, which lots are locked or encumbered, which rules apply, and when human review is required.
That is lot intelligence.
It is the difference between calculating gain or loss after the fact and managing the lot-level record before the decision is made.
Specific Identification Depends on the Record
Specific identification is not just a phrase in a tax memo. It depends on the taxpayer having a record that can support the identification.
That record needs to show the particular units selected for a transaction. It should preserve identifying details such as acquisition date, acquisition time where relevant, quantity, basis, wallet or account context, source transaction, and remaining availability.
Digital assets make this harder because the portfolio rarely sits still.
Assets move across wallets, custodians, exchanges, protocols, treasury accounts, and advisory workflows. Where the facts support non-taxable transfer treatment, movement between wallets should not cause the record to lose original basis history. A sale should not consume a lot that was already used. A charitable donation should not be documented after the fact with a vague description of "crypto donated." A planning decision should not live only in someone's notes.
Bedrock is designed to preserve the lot-level chain of evidence.
When a lot is created, transferred, selected, partially consumed, locked, assigned, or overridden, the record keeps the relevant context attached to the lot. The value is not only that the system can calculate the result. The value is that the result can be traced back to the lot-level decision that produced it.
Standing Instructions Make Policy Repeatable
Not every lot decision should require a one-off manual review.
Some organizations need repeatable policies:
- Define policies that evaluate highest-basis lots for certain treasury sales.
- Surface loss lots when tax-loss harvesting is the planning objective.
- Evaluate long-term lots for selected disposition types.
- Apply one rule to a treasury wallet and a different rule to an operating wallet.
- Fall back to FIFO only when no standing instruction or specific identification applies.
The important word is policy.
These are not generic preferences buried in a settings screen. They are instructions that should be scoped, applied consistently, and preserved in the audit history.
Bedrock's rule model is built around that idea. A standing instruction can define the repeatable treatment. When the rule fires, the selection is part of the record. When the rule is not enough, the item can be routed for review. When a reviewer overrides the rule, the reason belongs in the record too.
This gives treasury and tax teams two useful operating modes: policy for repeatable activity, and deliberate specific identification for higher-stakes planning moments.
Availability Is More Than Balance
A balance tells you how much of an asset exists.
It does not necessarily tell you what is available.
For digital asset treasury teams, availability can depend on more than quantity. A lot may be held in a particular wallet. It may be tied to a planning objective. It may be locked, assigned, restricted, or encumbered. It may carry a holding-period profile the team wants to preserve. It may be the wrong lot to consume if a donation, derivative, or year-end strategy is already in motion.
This is where dashboard-level reporting breaks down.
Knowing that the organization holds 100 BTC is different from knowing which lots make up that 100 BTC, where they came from, what basis they carry, how long they have been held, which quantities remain available, and which are already connected to another decision.
Bedrock tracks inventory at the lot level so availability is not reduced to a portfolio balance. Treasury can see what can be used. Tax can see the consequences of using it. Audit can see why the record changed.
The Audit Trail Should Explain the Decision
The weakest lot-selection workflows produce a number first and an explanation later.
That creates unnecessary risk. When a reviewer asks why a specific lot was selected, the organization may need to reconstruct the answer from exports, screenshots, Slack messages, spreadsheets, emails, and memory.
That is a poor foundation for a material digital asset reporting process.
The better model is to capture the reason when the decision is made.
Bedrock records the activity that changes the lot-level record: rule applications, manual assignments, overrides, locks, unlocks, allocations, and disposals. Those events should answer the review questions that come later:
- Which lot was selected?
- What rule or instruction selected it?
- Who changed the record?
- When did the change happen?
- Why was the change made?
- What quantity remains available?
- Which report or period did the decision affect?
That is what turns lot accounting from a calculation into a controlled workflow.
Lot Intelligence Changes the Planning Conversation
The most valuable lot work happens before the transaction.
A tax advisor evaluating a charitable donation needs to know which appreciated long-term lots are available. A finance team planning a treasury sale needs to understand the gain or loss profile of different lots. A controller preparing for period close needs confidence that prior decisions did not silently change. A CFO needs to know that tax, finance, and audit are not each maintaining a different version of the lot record.
Without lot intelligence, the organization asks, "What happened this year?"
With lot intelligence, the organization can ask, "Which lots should we use before this transaction happens, and how will that decision be documented?"
That shift matters. It moves the workflow from year-end reconstruction to controlled decision-making.
The Standard Is Defensible Selection
Digital asset tax lot accounting should not depend on invisible defaults, brittle spreadsheets, or after-the-fact explanations.
The standard should be defensible selection.
Every lot should carry its acquisition history. Every transfer should preserve basis when the facts support that treatment. Every standing instruction should be explicit. Every override should explain itself. Every consumed quantity should be removed from future availability. Every reported number should trace back to the lot-level decision behind it.
That is the role of Bedrock lot intelligence.
It gives digital asset treasury and tax teams a governed way to know which lots exist, which lots are available, which lots were selected, and why the result can be defended.
A default setting should not quietly make decisions your organization has to explain later.