We did it… again! Five questions from the KPMG Digital Assets Forum, answered with five queries

Last week I spent a morning at the KPMG Digital Assets Forum, an invitation-only event co-hosted by KPMG’s asset-management digital-assets practice and Hypernative at KPMG’s new Manhattan West offices. Four sessions, a room of asset managers, custodians, tax and legal practitioners, and the people running tokenization programs at large institutions. Small by design, and better for it: with no stage to play to, the speakers were precise. A depository go-live with a date. A tax regime with a penalty attached. A legal test you could apply to a smart contract. A counterparty problem described as a daily workload rather than a theme.

I had spent two days at the RWA Summit in Brooklyn a fortnight earlier and written up ten questions from it. It was striking how many of those came back in this room almost word for word, sometimes from the same people: real-time payment provenance, now from a bank’s wealth-risk head; the vault exit-window test; the missing instrument-identity layer. When the same question survives a change of room, audience and host, it is probably the right question. Those three I will not re-answer; where a new question lands on top of one of them, I say so. The queries in the earlier post still stand.

This forum added specificity. Five of its questions were new and sharp enough to deserve their own treatment. Each is answered the same way: a short query against SonarX data shares, run within days of the event, across every chain where the question applies. Everything below was queried on 17 and 18 September 2026, except the disposal side of the first ledger, added on 21 September.

1. “Exchanges will not have the cost-basis data”

The tax panel was the most useful third of an hour I have spent at a digital-assets event this year, and it covered ground nobody in Brooklyn touched. The panel’s starting point (general observations, not tax advice): the 1099-DA regime is live, brokers report proceeds and cost basis, and basis can be lost whenever an asset moves through a self-custody wallet or a peer-to-peer trade. One panelist, whose day job is exactly this, said plainly that the exchanges will not have the data. The forms will be wrong.

The chain does have the data. Every inbound transfer to a wallet is an acquisition lot with a price at the moment of receipt; every outbound is a disposal. Put the two sides together and you have a lot ledger. One wallet, one token, seven weeks, both directions:

SELECT datetime,
       CASE WHEN to_address = :wallet THEN 'IN' ELSE 'OUT' END AS side,
       source_value_text              AS raw_units,   -- exact, 18 decimals
       value                          AS qty,
       price_close                    AS price,
       usd_value                      AS usd,
       transaction_function_signature AS fn
FROM   ██████████████████████████████
WHERE  token_address = '████████████████████████████████████████'   -- LINK
  AND  :wallet IN (to_address, from_address)
  AND  datetime BETWEEN '2026-08-01' AND '2026-09-20'
ORDER  BY datetime, log_index;

Acquisitions: the lots. Raw units are exact; the LINK and basis columns are rounded for display. The smallest lots are tiny, not zero. Both real lots arrived through contract calls (exchange, bridge or vault settlement); the six dust rows are plain transfer calls.

The pooled average prints as $8.3400 through L2–L5 because a weighted average is insensitive to lots that carry no weight: the four dust lots move it by about 7 × 10⁻⁹ dollars. It moves only when L6 lands. That is correct behavior for a pool, and exactly why a pool is the wrong instrument for the US, where every receipt is a separate lot regardless of size.

Disposals: FIFO match against the lots above. Proceeds are the transfer’s USD value at the 30-minute reference price (see the note at the end of the section). Gain = proceeds − basis of the lots consumed.

Reconciliation, in exact base units. L1 − D1 − D2 = 11497155000000000000000; add L2+L3+L4+L5 = 261250000000000; total 11497155261250000000000 = D5 exactly. L6 + L7 + L8 = 11305754054436126725288; D6 = 11305754054436100000000; residual 26,725,288 base units (2.7 × 10⁻¹¹ LINK) left in the wallet. The ledger closes to the wei. A float sum would not have shown that residual. The exact integer string does. The same tables exist for every chain we index.

A note on method, because it decides what a number like “$8.4590” is allowed to mean. In the US, a running average is not a tax figure for digital assets at all: the average-cost method is available for mutual fund shares, not for digital assets, and under the 2024 final broker regulations and Rev. Proc. 2024-28 digital-asset basis is by specific identification where lots are adequately identified in time, otherwise first in, first out within each wallet or account. That is why the disposal table is the one that matters for a 1099-DA, and why every receipt, however small, is its own lot. In the UK it is the reverse: HMRC’s Section 104 pooling is a running average cost per asset, which is why the column stays in the first table. The forms want dollars and cents on the 1099-DA and permit whole dollars on the return; I have not found a rule that prescribes internal precision, which is why we carry the exact integer and round at the form.

What the two sides show together. The wallet made two small sends (D1: 3 LINK to an address ending …3321; D2: 3.125 LINK to one ending …0e84). Within a minute of each, dust arrived from addresses sharing the same first four and last four hex characters (L2–L3, L4–L5). Then two zero-value transfers left the wallet to further lookalikes (D3, D4). That is the shape of an address-poisoning attempt: the table shows the wallet as sender with top-level function transfer, and which of its own key or a delegated approval produced them is a trace-layer question, and the traces sit in the same warehouse. Then the wallet swept its full balance, including the dust, to a settlement contract, and the next day sold the second lot through CoW Protocol. The chain cannot say whether D1/D2 reached the intended counterparties or were themselves misdirected, but for a tax engine both are dispositions at fair value either way, and the six dust receipts are lots with near-zero basis that were disposed of in D5 and D6. A naive engine gets the lot count wrong; a correct one needs a dust rule; and whether a dust receipt is itself a taxable event is a question for the tax panel, not the warehouse.

Two caveats to carry. Prices: basis and proceeds above use a 30-minute reference grid (the price timestamp sits ~35 minutes before the transfer in this sample). That is a defensible fair-value proxy for receipts and for non-sale transfers (D1, D2, D5), but D6 is a CoW Protocol settlement, an actual sale, and its real proceeds are the execution price in the DEX swap tables rather than the reference price; joining those tables replaces the $3,165.61 estimate with the executed gain. Characterization: D1 and D2 are transfers to third parties with no on-chain consideration; whether they are sales, payments or gifts is a facts-and-circumstances question the chain cannot answer, and it changes the tax result.

The dust is visible as it lands, which is also the “in-flow, real time” half of what the security panel asked for. That panel, moderated by Hypernative, whose business is proactive security for onchain finance, detecting and preventing exploits in real time, made the case that as collateral starts moving around the clock, adding friction stops being an option and prevention has to be data-driven. Address-level transfer data at this grain is the raw material for exactly that.

2. “In a DeFi leverage loop, you do not know your lender”

An asset manager running a live leveraged product described the problem: the one-time bilateral underwriting of a prime-brokerage relationship becomes continuous monitoring of an anonymous, shifting pool. Who else is in this pool, how concentrated is it, how does it change. He said his team does this in-house, by hand, with each new use of leverage.

It is a GROUP BY. Net supplier position per account is deposits minus withdrawals; concentration is a share and a Herfindahl index.

WITH d AS (
  SELECT COALESCE(on_behalf_of, user_address) AS acct, SUM(usd_value) AS usd
  FROM   ██████████████████████████████
  WHERE  protocol = 'aave_horizon' AND reserve_symbol = 'RLUSD'
    AND  datetime >= '2026-01-01'
  GROUP  BY 1),
w AS (
  SELECT user_address AS acct, SUM(usd_value) AS usd
  FROM   ██████████████████████████████
  WHERE  protocol = 'aave_horizon' AND reserve_symbol = 'RLUSD'
    AND  datetime >= '2026-01-01'
  GROUP  BY 1),
n AS (
  SELECT COALESCE(d.acct, w.acct) AS acct,
         COALESCE(d.usd, 0) - COALESCE(w.usd, 0) AS net
  FROM   d FULL OUTER JOIN w ON d.acct = w.acct),
p AS (
  SELECT acct, net, 100 * net / SUM(net) OVER () AS pct
  FROM   n WHERE net > 0)
SELECT COUNT(*)                 AS suppliers,
       ROUND(SUM(net) / 1e6, 1) AS net_supply_m,
       ROUND(MAX(pct), 1)       AS top1_pct,
       ROUND(SUM(pct * pct))    AS hhi
FROM   p;

Run for every Horizon reserve with net supply, on Aave Horizon, Aave’s institutional RWA market on Ethereum, year to date:

A borrower against RLUSD on Aave Horizon does not have an anonymous shifting pool of lenders. It has one counterparty, an address supplying $150.8M of a $160.1M reserve. USTB has seven suppliers and three of them are effectively the whole reserve.

Then the same query for the same asset on the same protocol, across seven chains. Aave v3, USDC reserve:

Same protocol, same asset, same code. On Ethereum the USDC pool is as diffuse as a lending market gets (HHI 168). On BNB Chain one address is 82.5% of it. One Brooklyn panelist’s view was that the same protocol on a second chain often carries materially different risk. Here is the check, and it took seven copies of one query.

3. “How you write the contract decides whether you are in or out”

The vault discussion produced the cleanest legal decomposition I have heard at any event this year. The moderator’s version ran roughly as follows (general observations, not legal advice). A receipt token means the assets are still the depositor’s. No custody plus no commingling means no 40 Act fund. Discretionary management means the curator needs to be a registered adviser, but the vault itself need not be a fund. Every one of those tests turns on how the contract is written.

Contracts declare what they are. Our ABI catalog records, for every contract with a resolved interface, the events it can emit. The legal tests map onto declared events.

SELECT COUNT(DISTINCT CASE WHEN event_signature
              = 'Deposit(address,address,uint256,uint256)'
            THEN contract_address END) AS erc4626_receipt_token,
       COUNT(DISTINCT CASE WHEN event_name IN
              ('SetCurator', 'SetIsAllocator', 'SubmitCap', 'SetCap', 'SetGuardian')
            THEN contract_address END) AS discretionary_curator,
       COUNT(DISTINCT CASE WHEN event_name IN
              ('SubmitTimelock', 'SetTimelock', 'CallScheduled', 'MinDelayChange')
            THEN contract_address END) AS has_timelock
FROM   ██████████████████████████████;   -- run once per chain

Eight chains, 18 September 2026:

Sixty thousand contracts declare the ERC-4626 receipt-token interface; separately, 2,326 contracts declare a curator or allocator role, which is the discretion test, and about 7,600 declare a timelock, which is the exit window. Intersect the three and you have a first-pass classification of every vault on eight chains against the decomposition the moderator gave. Arbitrum’s count is dominated by a single factory pattern, which one more predicate separates out. That is the kind of thing an engineer spots in a minute and a dashboard never does.

Declared interface is not verified behavior, and “custody” in the legal sense turns on who can move the assets, which needs the trace layer rather than the event layer. Both are in the same warehouse.

4. “Databases of the future need to speak tokens”

The closing fireside argued that tokens are becoming software objects that carry their own rules: who may hold them, when they may trade, whether the issuer can freeze or claw back. In Brooklyn the instrument-identity layer was described as missing. Here the argument was that the tokens themselves are starting to supply it.

The ABI catalog can count that too.

SELECT COUNT(DISTINCT CASE WHEN event_name IN
              ('IdentityRegistryAdded', 'ComplianceAdded', 'IdentityRegistered',
               'ClaimTopicsRegistrySet', 'TrustedIssuersRegistrySet')
            THEN contract_address END) AS erc3643_permissioned,
       COUNT(DISTINCT CASE WHEN event_name IN
              ('AddressFrozen', 'TokensFrozen', 'Blacklisted', 'AddedBlackList',
               'BlackListed', 'Frozen', 'FreezeAddress')
            THEN contract_address END) AS issuer_freeze_power,
       COUNT(DISTINCT CASE WHEN event_name IN
              ('RecoverySuccess', 'TokensRecovered', 'Clawback')
            THEN contract_address END) AS issuer_recovery_power
FROM   ██████████████████████████████;   -- run once per chain

Nearly two thousand contracts on eight chains declare the ERC-3643 identity-and-compliance interface, and Polygon, not Ethereum, is where the largest share of them lives. Ten thousand declare an issuer freeze power. Whether a given issuer has ever used that power is the freeze-history query from the Brooklyn post, and the two join on the contract address.

5. “One transaction will span several ledgers”

The same fireside described atomic transactions spanning Ethereum, its L2s and private permissioned networks, and asked how anyone reconstructs one for audit. Nobody can index a bundle that does not yet exist in production. But the legs that cross public chains today are attributable, bridge by bridge.

SELECT destination_chain,
       COUNT(*)                      AS bridge_txns,
       COUNT(DISTINCT sender_address) AS senders,
       ROUND(SUM(usd_amount) / 1e6)  AS usd_m,
       COUNT(DISTINCT platform_name) AS bridges
FROM   ██████████████████████████████
WHERE  datetime >= DATEADD(day, -30, CURRENT_TIMESTAMP)
GROUP  BY destination_chain
ORDER  BY usd_m DESC;

Out of Ethereum in the thirty days to 18 September: 485,160 bridge transactions from 166,948 senders, $13.3bn, over 27 bridge protocols. The legs that name a destination reach 129 chains. Arbitrum took $2.11bn, Base $1.77bn, Plasma $1.64bn, Polygon $1.57bn, Monad $1.15bn, Solana $0.97bn. Linea, which the fireside described as a settlement layer being built for institutions, took $3.5M in 1,183 transactions: early days, and measurable from the first one.

Each row carries the sender, the receiver on the destination chain, the token, the amount and the bridge, and the destination chain is indexed too (Linea’s last block was in the warehouse within hours). So the public legs of a multi-ledger transaction can be joined end to end today. The private legs are a conversation with whoever runs the network.

What a small room gets right

A forum of four sessions produced five questions precise enough to be answered with a query each, and confirmed three more from Brooklyn by asking them again. That is a good ratio, and it says something about who was in the room: people close enough to production to know exactly what they are missing. My thanks to KPMG and Hypernative for the invitation.

Each of the five queries above is short because someone had already shaped the tables to answer questions like these. That person comes with the data. If your version of one of these questions is sharper than the one asked on stage, send it over, and we will answer it the same way.

All figures from SonarX Snowflake data shares, queried 17 and 18 September 2026 (disposal rows in section 1: 21 September). Section 1 prices are a 30-minute reference grid; the section’s own note covers what that means for the one actual sale in the ledger. Lending-pool figures are net flows since 1 January 2026, not full positions. ABI-catalog counts are contracts declaring an interface, not verified behavior. Bridge figures cover the Ethereum side of each transfer; per-chain rows cover the transfers that name a destination chain on the Ethereum leg, and the totals cover all of them. Nothing in this post is tax, legal or investment advice.