Welcome to USD1snapshots.com

Overview

USD1 stablecoins (digital tokens intended to be stably redeemable one to one for U.S. dollars) are often described as "simple." In practice, even a plain token can be used across many blockchains (shared ledgers maintained by many computers), held in custodial accounts (accounts where a service holds assets on your behalf), and moved through smart contracts (programs that run on a blockchain). Each of those layers produces data.

USD1snapshots.com is part of the USD1 stablecoins network (a descriptive set of educational sites about USD1 stablecoins). It is not an issuer site, and it does not represent any "official" token.

A snapshot (a point-in-time record) is one of the most useful ways to make that data understandable. A snapshot can answer questions like:

How many units of USD1 stablecoins exist at a specific time?
How many units are held at particular addresses (identifiers on a blockchain)?
How much activity occurred over a day, week, or month?
How do published reserve or backing statements line up with token supply?

USD1snapshots.com focuses on the idea of snapshots as a neutral reporting tool. The goal is not hype or marketing. It is to explain what snapshots are, what they can and cannot tell you, and how to read snapshot-style reports with a critical eye.

What a snapshot means for USD1 stablecoins

A snapshot is a carefully chosen "freeze frame" of information. The core idea is straightforward: pick a reference moment, describe exactly what data was collected, and make the result verifiable.

For USD1 stablecoins, snapshots usually fall into two broad categories:

On-chain snapshots (records taken from a blockchain itself). These are anchored to a specific block (a batch of transactions recorded together) or to a specific block number and block hash (a one-way digital fingerprint of the block contents). Because blockchains are append-only ledgers (records that can be added to but are hard to rewrite), you can often reproduce the same snapshot later if you use the same reference block.
Off-chain snapshots (records taken from outside a blockchain). These might include bank account statements, custodian reports, or third-party attestations (assurance reports by an independent professional). Off-chain snapshots can be important because USD1 stablecoins are designed to be redeemable for U.S. dollars, and redemption is ultimately an off-chain process in many setups.

A helpful way to think about it is "liabilities and backing." Token supply and balances describe liabilities (what is owed to holders). Reserve or backing reports describe assets (what is held to support redemption). Good snapshot reporting makes the connection between these two sides explicit, without pretending that a single number tells the whole story.^[1]

What can be captured in a snapshot

The word "snapshot" sounds like one thing, but in practice it can mean several different datasets. For USD1 stablecoins, common snapshot targets include:

Total supply at a reference block (the number of units that exist at that moment).
Balance distribution (how units of USD1 stablecoins are spread across addresses).
Flow summaries (how many units moved, and how often, over a chosen time window).
Market and liquidity conditions (how easily USD1 stablecoins can be exchanged for U.S. dollars without large price moves) on trading venues.
Contract state (values stored inside a smart contract, such as pause flags or role assignments).
Bridge state (records related to moving USD1 stablecoins between chains, if bridging is used).
Reserve or backing reports (cash and cash-equivalent holdings (assets that can usually be converted to cash quickly with low risk), government securities, or other assets that are stated to support redemption).^[1]

Price snapshots are a special case. USD1 stablecoins are intended to track one U.S. dollar, but secondary market prices can drift during stress, outages, or liquidity shocks (sudden changes in the ability to trade). A price snapshot can be useful for understanding conditions, but it should be interpreted alongside redemption access and backing disclosures, not as a standalone scorecard.^[5]

Not every snapshot will include every category. The key is that a snapshot should be explicit about scope. For example, "on Ethereum mainnet at block 20,000,000" is a clear scope. "All USD1 stablecoins everywhere" is often ambiguous unless the report also lists which chains and which contract addresses were included.

On-chain snapshots

On-chain snapshots are attractive because they are reproducible. If you know the chain and the reference block, you can typically re-run the same query later and check whether you get the same answer.

That said, "on-chain" does not mean "simple." Here are the main building blocks of on-chain snapshotting.

Anchoring the snapshot to a reference block

Most on-chain snapshots are anchored to a specific block number, block hash, and timestamp (the time label recorded with the block). The block hash matters because it helps uniquely identify the exact block you mean.

Block timing varies by chain, and some chains can experience reorganization (a short-lived event where the network replaces recent blocks with a different version). For that reason, some snapshot methods wait for practical finality (the point at which a block is very unlikely to be reversed) before treating a snapshot as stable.^[2]

Reading token supply and balances

Many token designs keep a stored total supply value and a mapping from addresses to balances. A snapshot that reports "total supply" is usually reading that stored value at the reference block.

A snapshot that reports balances has more moving parts. On large networks, there can be millions of addresses. A complete balance list can be very large, so many reports summarize balances into buckets (for example, "top holders" or "holders above a threshold"). Summaries are useful, but they can also hide important details, such as contract addresses that hold funds for many users.

A common approach is to publish:

The total supply number at the reference block.
The balance of a named set of addresses (for example, known exchange wallets).
A distribution summary that shows how concentrated holdings are.

When reading those summaries, remember that an address is not the same as a person. One address can represent many users (for example, in a custodial wallet), and one user can have many addresses.

Verifiability with hashes and proofs

Snapshot data is often shared as a file or report. One straightforward integrity check is to publish a hash (a one-way digital fingerprint) of the snapshot file so that anyone can verify the file has not been altered after publication. The NIST Secure Hash Standard is a widely referenced standard for hash functions used for integrity checks.^[3]

For very large datasets, reports sometimes use a Merkle tree (a tree of hashes that allows efficient membership proofs). With a Merkle tree, a report can publish a single root hash that commits to the full dataset, and individual users can verify that their specific balance record is included without downloading the entire dataset. Ethereum uses related authenticated structures (data structures designed to be verifiable with hashes) for state commitment, which is why the concept shows up often in blockchain reporting.^[4]

Multi-chain reality

USD1 stablecoins may exist on multiple networks as separate contracts or as wrapped representations (tokens that represent a claim on another token). A snapshot that focuses on one chain is not necessarily wrong, but it is incomplete for questions about global supply.

A multi-chain snapshot needs clear rules:

Which networks are included?
Which contract addresses represent USD1 stablecoins on each network?
Are bridged or wrapped representations counted, and if so, how is double counting avoided?

Without those rules, two reports can disagree while both are "correct" within their own scopes.

Off-chain snapshots

Off-chain snapshots matter because redemption for U.S. dollars typically relies on assets held in the traditional financial system. Even if all token balances are visible on-chain, the assets that are intended to back redemption are often held off-chain, such as in bank deposits or short-term government securities.

A good off-chain snapshot report usually answers three questions:

What assets are being counted as backing (for example, cash, Treasury bills, overnight reverse repurchase agreements (very short-term secured funding transactions common in money markets), or other instruments)?
Who holds or custodies those assets (for example, a bank, a broker, or a qualified custodian)?
What is the measurement date and time, and how does it match the on-chain supply snapshot?

Many policy discussions about stablecoins emphasize that risk depends on the quality, liquidity, and transparency of backing arrangements, and that operational and legal risks can matter as much as asset composition.^[1]^[5]

Attestations versus audits

People often use "audit" as a catch-all term. In practice, an attestation (an assurance report by an independent professional) can be narrower in scope than a full financial statement audit (a detailed examination of financial statements). Snapshot-style publications sometimes include attestations that focus on a specific point in time, such as assets and liabilities on a given date.

The important reader skill is to look for the scope and the criteria. What exactly was tested, under what standards, and what was not included? If a report only covers a single day, it may not tell you much about how backing behaves during stress periods.

Timing alignment

A recurring challenge is that "end of day" on a blockchain is not the same as "end of day" in banking. Blockchains operate continuously, while banking systems often report using business-day cutoffs that vary by region.

Snapshot reports can handle this by stating:

The on-chain reference block and its timestamp.
The off-chain reporting cutoff (for example, close of business New York time).
Any known timing mismatch between the two.

Even small timing gaps can matter when token supply changes quickly.

Snapshot design choices

Not all snapshots answer the same kind of question. A well-designed snapshot makes its design choices explicit, because those choices affect what conclusions are reasonable.

Point-in-time versus time-window summaries

A point-in-time snapshot (a single freeze frame) answers questions about a specific moment, such as "How many units of USD1 stablecoins exist at this reference block?" A time-window summary (a report that covers activity over a start time and an end time) answers questions about change, such as "How many units were transferred during the window?"

Neither approach is universally better. Point-in-time snapshots are usually easier to reproduce because they anchor to a block. Time-window summaries can be more intuitive for reporting cycles such as daily or monthly statements, but they depend on how the report defines the start and end boundaries.

Clock time versus block time

Blockchains record transactions in blocks, not in wall-clock seconds. A report might say it is "as of 12:00 UTC" but the underlying anchor might be "the first block after 12:00 UTC." That difference can matter when activity is heavy.

Strong snapshot reports typically include both:

A human-readable time label (often UTC, which is a time standard used worldwide).
A precise chain anchor (block number and block hash).

Full data versus minimized data

Some reports aim to be fully transparent by publishing a complete list of balances. Others aim to minimize exposure by publishing only summaries or cryptographic commitments (hash-based commitments such as a Merkle root) that still allow verification of specific records.

Minimized data approaches can reduce privacy and security concerns, but they also require readers to understand what is and is not being revealed. This is another place where clear scope statements matter.

Data source choice and trust boundaries

On-chain data can be gathered by running a node (a computer that participates in a blockchain network) or by querying an API (application programming interface, a structured way for software to request data) provided by a third party. Both approaches can be valid.

The trust boundary (the point where you start relying on someone else's system) is different:

With your own node, you rely mainly on the network rules and your software.
With a third-party API, you also rely on the provider to return complete and correct results.

Many reports use third-party infrastructure for practicality. When they do, it helps to say so.

Why snapshots matter

Snapshots are not just a data exercise. They affect how people understand risk and trust.

Transparency without overpromising

Transparency is useful, but it is easy to overpromise. A snapshot can show what is recorded at a point in time. It cannot prove future behavior. For example, seeing reserves on a date does not guarantee those reserves will remain available, nor does it guarantee redemption will be smooth during market stress. Research and policy work repeatedly note that stablecoins can have run-like dynamics (rapid redemption pressure) if confidence falls.^[1]^[6]

Operational monitoring

Snapshot reporting can highlight operational issues. Examples include:

Contract upgrades (changes to smart contract code) and how they affect token rules.
Pauses or restrictions (controls that can stop transfers, depending on design).
Large mint or burn events (creation or destruction of units) that change supply.

Operational issues matter because they can affect usability even if backing assets are strong.

Accounting and reconciliation

Individuals and organizations often need a record of holdings for bookkeeping, financial reporting, or tax preparation. A snapshot can support that record keeping by providing a point-in-time balance reference.

However, blockchain balances can differ from what a custodian shows if funds are pooled or if there are pending internal transfers. For that reason, a snapshot is best understood as one input into reconciliation (the process of making sure two records agree), not as the only record.

Compliance and financial integrity

Some jurisdictions require virtual asset service providers (businesses that exchange, transfer, or safeguard digital assets) to follow AML (anti-money laundering controls) and related rules. Snapshot data can support monitoring for unusual patterns, sanctions screening, and Travel Rule (information-sharing requirements for certain transfers) processes. FATF guidance and updates discuss expectations for risk-based controls in the virtual asset sector.^[7]

This does not mean that public snapshot data reveals personal identity. It usually does not. But it can contribute to risk monitoring when combined with other information held by regulated services.

How to interpret snapshot reports

If you are reading a snapshot report about USD1 stablecoins, a few reader habits can help you avoid common misunderstandings.

Start with scope and definitions

Look for:

Which chain or chains are covered.
Which contract addresses were used to represent USD1 stablecoins.
The exact time anchor (block number and timestamp, or a clear time label).
Whether the report covers balances, supply, activity, backing, or some combination.

If a report does not state these items, treat conclusions as tentative.

Check whether supply matches the story

A supply snapshot is usually straightforward. The harder part is interpretation:

A high supply number is not automatically good or bad.
A fast-changing supply can be normal (for example, if demand for settlement varies) or it can reflect stress (for example, rapid redemptions).

Context matters. Some policy work highlights how stablecoin usage can grow quickly and how that growth can interact with payment markets and regulation.^[6]

Understand concentration and pooled addresses

When you see that a few addresses hold a large share of USD1 stablecoins, that might mean:

A small number of large investors, or
A small number of custodians holding on behalf of many users, or
Contracts such as liquidity pools (smart contracts that hold funds used for automated trading).

A snapshot report should ideally label known pooled addresses, but labeling is imperfect and can change over time.

Look for reproducibility signals

Strong reports make it easier for others to replicate results. Signals include:

The reference block number and block hash.
A description of the method used to query balances.
A published hash of the snapshot dataset file for integrity checking.
Clear notes about exclusions (for example, contracts that were not included).

If you cannot replicate a snapshot in principle, you are being asked to trust the report writer more than the underlying ledger.

Be cautious with off-chain backing claims

Backing claims are important, but they are not all the same. When reading a reserve or backing snapshot, ask:

What assets were counted, and are they liquid (easy to convert to cash quickly)?
Are there credit risks (risk that an issuer cannot pay) in the backing assets?
Are there legal claims that could limit access to assets during insolvency (when an entity cannot pay its debts)?
Who produced the report, and under what scope?

IMF work highlights that stablecoins combine elements of payments, capital flows, and legal frameworks, and that managing risks often requires more than technical transparency.^[5]

Common pitfalls and limitations

Snapshots are powerful, but they have limitations that readers should keep in mind.

Reorganization and timing uncertainty

If a snapshot is taken very close to the chain tip, later reorganization events can change what "the" block was at a given time label. Many chains reduce this risk with finality rules, but the concept still matters, especially across different networks.^[2]

A careful report states whether it waited for practical finality.

Incomplete chain coverage

If USD1 stablecoins appear on multiple networks, a single-chain snapshot is partial. A multi-chain snapshot can still miss networks if contract addresses are unknown or if representations are created through unofficial wrappers.

This is why scope disclosure is so important.

Double counting across wrappers and bridges

If a wrapped representation is backed by locked units on another chain, counting both the locked units and the wrapped units as separate supply would double count. Avoiding that requires understanding bridge mechanics and how claims are structured.

Privacy and data minimization

Publishing full balance lists can create privacy and security risks, even though addresses are not direct identities. Some reports use Merkle proofs to allow verification without publishing a full list, which can reduce exposure.

Still, data minimization (collecting and sharing only what is needed) is a healthy principle when building snapshot systems.

Snapshots do not remove stablecoin risk

It is tempting to think that more data equals less risk. In reality, stablecoins can face:

Backing asset risk (quality and liquidity of reserves).
Operational risk (system failures, key compromise, smart contract flaws).
Legal and regulatory risk (changes in rules across jurisdictions).
Market structure risk (liquidity fragmentation (when trading is spread across many venues so no single venue is deep), reliance on a few intermediaries).

BIS and other policy sources emphasize that stablecoins can pose challenges for financial stability and monetary sovereignty (a country's ability to manage its own money and payment system) without strong governance and oversight.^[6]

FAQ

Is a snapshot the same as a balance statement?

Not exactly. A snapshot is a point-in-time record. A balance statement is a document that may summarize balances and activity over a period and may include additional context, such as pricing conventions, fees, or internal transfers. A snapshot can support a balance statement, but it usually does not include every detail a statement might include.

If balances are public on-chain, why do snapshots matter?

Public data is not the same as understandable data. Snapshots provide a structured way to anchor questions to a specific moment, summarize large datasets, and support repeatable verification. They can also connect on-chain liabilities (token supply and balances) to off-chain backing reports.

Can a snapshot prove that USD1 stablecoins are fully backed?

An on-chain snapshot can show token supply and balances. It cannot directly prove what assets exist off-chain. Off-chain reports can describe assets, but their strength depends on scope, standards, and timing alignment. In other words, snapshots can improve transparency, but they do not replace governance, legal clarity, and risk management.^[5]

What is the simplest integrity check for a snapshot file?

Publishing a hash of the snapshot file is a common starting point. Anyone who downloads the file can compute the same hash and confirm the content matches what was published. Hash standards such as NIST FIPS 180-4 describe widely used secure hash functions for integrity checking.^[3]

Do snapshots cover custodial holdings accurately?

A snapshot can show what a custodial address holds on-chain, but it cannot show the internal allocation inside a custodian unless the custodian publishes that breakdown. That is why concentration data must be interpreted carefully: a large address can reflect a pooled account for many users.

Why do different snapshot reports sometimes disagree?

Common reasons include different chain coverage, different contract address lists, different timing anchors, and different rules for handling wrappers or bridged representations. Disagreement is not automatically evidence of bad faith, but it is a signal to check scope and methodology.

Glossary

Address (an identifier on a blockchain): A string that represents an account or smart contract.
API (application programming interface, a structured way for software to request data): A method for retrieving blockchain data from a service.
Block explorer (a website that lets you search blockchain data): A tool for viewing transactions, blocks, and token activity.
AML (anti-money laundering controls): Policies and systems designed to reduce illicit finance.
Attestation (an assurance report by an independent professional): A report that provides a conclusion about specific information, often at a point in time.
Block (a batch of transactions recorded together): A unit of blockchain history that links to previous blocks.
Blockchain (a shared ledger maintained by many computers): A database where updates are agreed by network rules.
Bridge (a mechanism for moving tokens between chains): A system that locks or burns tokens on one network and releases or mints on another.
Finality (the point when reversal is very unlikely): A property that helps snapshots remain stable.
Hash (a one-way digital fingerprint): A function output used to check integrity of data.
KYC (know your customer identity checks): Processes used by regulated services to verify identity.
Merkle tree (a tree of hashes for efficient proofs): A structure that lets you prove a record is included in a dataset.
Node (a computer that participates in a blockchain network): Software that stores and verifies blockchain data.
Off-chain (outside a blockchain): Data and processes handled by traditional systems, such as banks.
On-chain (recorded on a blockchain): Data that is part of the ledger state.
Reconciliation (the process of making two records agree): Comparing two systems and resolving differences.
Redemption (exchanging token units for U.S. dollars): The process that stablecoins are designed to support.
Smart contract (a program that runs on a blockchain): Code that controls token logic and other on-chain actions.
Trust boundary (the point where you rely on someone else's system): A place where assumptions about data completeness or correctness change.
UTC (a time standard used worldwide): A common reference time used in many technical and financial reports.

Disclaimer

This page is general educational material about snapshots and reporting concepts for USD1 stablecoins. It does not provide financial, legal, or tax advice. Always consider your local rules and your own risk tolerance when making decisions.