
A trustee at a midsize regional bank receives a call. A beneficiary has inherited cryptocurrency. The position is substantial—Ethereum held across three wallets—and the trustee’s job is clear-cut. Assume fiduciary responsibility, inventory the assets, establish cost basis, and manage distributions according to the trust terms.
The trustee logs in to the bank’s trust accounting system. The system has no native field for crypto holdings, no pricing mechanism or way to track movements across wallets as a single fiduciary position, no logic for handling staking rewards earned by the beneficiary.
The trustee runs the problem past the technology team. The response: Work around it. Add a note. Handle pricing manually. Treat rewards as they come in; classify them later.
Each of those shortcuts assumes digital assets behave like the assets the system was built for. They don’t. A beneficiary holding Bitcoin doesn’t get a single daily price. The asset trades continuously across multiple exchanges at slightly different prices. A staking position in Ethereum doesn’t generate a dividend. It generates a reward: new Ethereum tokens on a rolling basis. That reward might be classified as principal appreciation (an increase in the asset’s unit count) or as income (a distribution from the staking protocol), depending on the trust agreement, the trustee’s reading of fiduciary law, and the state in which the trust was established.
Stablecoins introduce a third problem. If a trust holds USDC, the trustee might assume that settlement in stablecoins rather than ACH changes how to classify principal and income. It doesn’t. Principal and income classification under the Uniform Principal and Income Act is rules-based, driven by the legal nature of distributions—interest and dividends flow to income, capital gains stay principal—regardless of settlement method. Yet this assumption persists in legacy systems, creating operational ambiguity that trust accounting infrastructure was never designed to resolve.
These aren’t edge cases anymore. Digital asset estates are reaching trust departments at regional and community banks. The workarounds that have held so far won’t survive an examiner’s inquiry, a beneficiary dispute, or a cost basis audit.
The Fix
Pricing needs to move from batch to continuous, with trustees defining a valuation hierarchy—which exchange is the primary source, at what deviation a price gets flagged—rather than accepting a single custodian feed.
Classification of staking rewards needs to be captured at the point of receipt. The rationale goes in the system of record, not a memo or spreadsheet—so it survives personnel changes and regulatory exams.
Cost basis needs to attach to the instrument, not the wallet. A transfer between wallets under the same beneficial ownership is not a disposal. Systems that treat it as one are generating phantom tax events and making accurate gain reconstruction impossible.
The Missing Piece
The custody infrastructure, pricing APIs, and classification frameworks already exist—in pieces, across vendors. What’s missing is a trust accounting system that assembles them and treats digital assets as assets, not exceptions. It doesn’t require a wholesale rebuild—just a new control layer.
Figure 1: Bridging the Gap to Digital Asset Readiness

Source: Datos Insights
The left side of Figure 1 is the current state: batch pricing, static lot structures, wallet-based tracking, and manual classification memos—a model built for assets that don’t trade continuously or generate protocol-based rewards. The right side is the target: continuous valuation, event-level classification, and cost basis that follows the instrument, not the wallet. The bridge is an operating model, not a new system—one that lets trustees evidence how assets were valued, how rewards were classified, and how basis was preserved over time. The result: digital assets move from manual exceptions to governed fiduciary positions. Trustees shouldn’t wait for vendors. The assets are already in the portfolios.