Onchain data for tokenized assets: issuance, transfers, and control events
A tokenized treasury fund is a regulated security that lives on a public chain. SQD serves the events it emits, issuance, transfers, and the issuer's own control events, decoded and keyed by topic0, across 225+ networks. The events a curated token API leaves out are the ones a monitoring desk needs.
Built for RWA at scale
Asset lifecycle in the log stream
Issuance (a Transfer from the zero address), redemptions, transfers, and the issuer's own events, each with the exact block and transaction. The same query over a wider window is the asset's full issuance and transfer history, decoded from one endpoint.
Issuer control events, not just transfers
A regulated token emits more than Transfer. BUIDL pairs each mint with an Issue event; ERC-3643 (T-REX) tokens emit AddressFrozen, TokensFrozen, Paused, and RecoverySuccess. The Portal hands back every log keyed by topic0, the standard and issuer-specific alike, to decode against the ABI.
Cross-chain, one query shape
A fund deployed on Ethereum, Polygon, and Arbitrum is the same decoded-log query with the dataset name and per-chain contract swapped. Pin the per-chain address: an event signature is global, and the same ticker can resolve to an unrelated token on another chain.
Built for your own models
The data is the events the contract emits, not a reconstructed per-holder balance series. Holder positions, concentration ratios, and NAV are aggregations you build on your own rows, from the issuance and transfer history the Portal serves.
BlackRock's BUIDL, its onchain life in one query
BUIDL is the BlackRock USD Institutional Digital Liquidity Fund, a tokenized money-market fund (0x7712...2aec). It is permissioned: only approved wallets hold it, and each share tracks a dollar. One bounded query returns every BUIDL log in a block. At block 25,344,852 it distributed yield by minting new shares to 33 whitelisted wallets in a single transaction, each a separate mint:
- 0xed71…cf72 4,693.97
- 0xf2f4…510f 871.21
- 0xe6a8…13b8 499.56
- 0x12c0…b0b4 362.81
- 0xce90…ada6 262.96
- and 28 more in the same transaction, down to 0.03 BUIDL
Transfer from the zero address, the largest 4,693.97 shares.
The query is one filter on the asset's contract over one block. No node, no per-issuer integration:
A monitoring agent reads the issuance off the Transfer-from-zero rows, matching topic0 to the known ERC-20 signature. The same query on a wider window is the fund's full issuance and transfer history. Pinned to a fixed block, you can run it and get exactly this.
The control events a curated API leaves out
A regulated token emits more than transfers, and the extra events ride in the same log stream. Every BUIDL mint is paired with an Issue(address,uint256,uint256) event the standard ERC-20 ABI does not recognize. Tokens built on the ERC-3643 (T-REX) standard emit a shared compliance vocabulary:
- AddressFrozenAccount frozen or unfrozen
- TokensFrozenPartial balance frozen
- PausedTransfers halted
- RecoverySuccessTokens recovered to a new wallet
The Portal hands back every log keyed by topic0, the standard ones and the issuer-specific ones alike; you decode the issuer events against the ABI. Curated token APIs are built around the ERC-20 surface (transfers and balances), so these control events tend not to be exposed as queryable, decoded data. That is the harder thing, and it is the point of reading logs directly off the Portal.
One gotcha: pin the per-chain contract, not the ticker. An event signature is global, and the same symbol can resolve to a different token on another chain. Resolving BUIDL on Base does not return BlackRock's fund; it lands on an unrelated token with 18 decimals instead of 6, so a symbol-based filter would watch the wrong contract and misread every amount.
Movement and control events, not balances or reserves
Events, not a balance series
The data is the events the contract emits: issuance, transfers, control actions, each with a block and a transaction. Holder positions over time, concentration ratios, and NAV are aggregations you build on those rows, not fields the API returns.
Onchain trail, not proof of reserves
Onchain events attest to onchain actions only. The BUIDL issuance proves shares were minted to those wallets; it does not prove the offchain treasuries behind them. A precise, timestamped trail of onchain activity, kept separate from proof of reserves. See the full walkthrough in the RWA monitoring guide.
Any tokenized asset, the same query shape
SQD does not gate which RWA protocols are supported. Any tokenized contract on a supported chain is indexable through the same decoded-log query.
What teams build with SQD
Other ways teams use SQD
Each of these runs on the same SQD data layer.
A DEX swap settles its token movement in nested internal calls; an event-log-only feed sees the receipt, not the execution.
SQD sits at the extract-and-decode end of the analytics pipeline.
A raw event log is hex-encoded topics and data.
Query any address and get its history: token transfers, native and internal value, NFT movements, and contract calls, across 225+ networks through one query shape.
Onchain, every stablecoin movement is a Transfer event: a mint is a transfer from the zero address, a burn is a transfer to it, a payment is one between two wallets.
Most indexers give you event logs.
Frequently asked questions
How does SQD index tokenized RWAs?
Which RWA protocols are covered?
Can I get a verifiable trail of a tokenized asset's activity?
How does the data flow into ERP or accounting systems?
Your blockchain data infrastructure, handled.
Private Portal. Dedicated. Validated. Managed. Tell us what you're building, we'll show you what it looks like on SQD.
validated data
for Enterprise
serving data