U.S. virtual-currency analysis is often derailed by product labels. A team says it is a protocol, an aggregator, a wallet, a DAO, a marketplace, or a non-custodial interface and assumes the label decides the outcome. U.S. federal guidance has instead emphasized facts and circumstances, including what a person does, for whom, and how value moves. That means product and engineering teams can improve legal review by documenting functions precisely before asking for a conclusion.
This guide is a preparation framework, not legal advice and not a complete survey of federal or state law. It focuses on the factual record needed to examine money-transmission and related questions involving convertible virtual currency. Securities, commodities, sanctions, consumer-protection, tax, privacy, state licensing, and other regimes may require separate analysis. The goal is to replace slogans with transaction diagrams, permissions, contracts, and operating evidence that counsel can evaluate.
Describe each product path as a transaction
Create a separate flow for every material user journey: purchase, sale, swap, transfer, deposit, withdrawal, bridge, payment, staking-related movement, liquidity action, wallet recovery, or token distribution. Show the user, counterparties, legal entities, wallets, contracts, accounts, relayers, and service providers. Mark when the user gives an instruction, when value is accepted, when control changes, and when value is transmitted or made available. Include failed and canceled paths, not only the happy path.
Document what changes between channels. An API customer may receive a managed routing service while a retail user calls a public contract. A wallet may be self-custodial for routine transactions but use a hosted recovery process. An interface may add a proprietary relayer or sponsor fees. These differences can matter. Avoid a single diagram labeled “the protocol” when the commercial product consists of several distinct services. Link each flow to the product version and applicable terms.
Identify acceptance and transmission facts
For each flow, ask who receives value or an instruction to move value, who has the ability to redirect it, and who causes it to reach another person or location. Record custody, possession of private keys, smart-contract permissions, transaction construction, signing, relay, and settlement. Non-custody is an important fact but should not be used as a substitute for analyzing the rest of the service. Some products influence movement without holding unilateral keys, while others merely provide tools that the user operates.
Be precise about technical control. A smart contract may execute deterministically after a user signs, yet an operator may choose the route, operate an intermediate address, or have an upgrade path. Conversely, a website may display data while the user independently constructs and submits a transaction. Counsel needs to know who can modify fields, withhold submission, substitute a destination, reverse a pending instruction, or intervene after broadcast. Test the production system rather than relying only on design documents.
Map administrators, exchangers, users, and service roles
Identify every person or entity that creates, issues, redeems, exchanges, brokers, routes, validates, administers, or uses the virtual currency in the relevant business model. The same participant can have different roles in different flows. A token issuer may also operate a redemption service. A software company may publish a wallet and separately run an exchange feature. A DAO contributor may write code while a foundation contracts with users. Keep roles connected to specific activities instead of assigning one permanent label to an organization.
Record whether activities are performed as a business and for whom. Include compensation, recurring operations, customer promises, service agreements, and transaction volume. Map agents and contractors, because outsourced execution does not necessarily remove the principal’s role. Also identify activities that are genuinely personal use or independent network participation. The factual matrix should let a reviewer distinguish the software, the network, the service, and the business relationships around them.
Examine hosted and unhosted wallet features separately
Wallet products vary widely. Document who controls keys, how transactions are built, whether the provider can block or alter them, how recovery works, whether assets pass through provider-controlled addresses, and whether the wallet contains exchange, transfer, purchase, or payment services. A user-controlled key does not answer what a bundled feature does. Treat each embedded service as its own flow and identify the entity that provides it.
Recovery and security features deserve special attention. Multi-party computation, social recovery, policy engines, co-signing, and transaction screening may create different capabilities depending on implementation. Describe whether the provider’s share is necessary, discretionary, automated, or replaceable. Show what happens if the provider refuses or is unavailable. Avoid marketing terms such as “self-custody” unless the technical and contractual facts support the exact user control being claimed.
Document decentralized exchange and application facts
For a decentralized exchange or application, map contract deployment, upgrades, admin functions, routing, token lists, liquidity arrangements, fees, interface operation, support, governance, and incident response. Identify the parties who perform those tasks and whether they act independently or through an organization. The existence of autonomous code is one fact in a broader business-model analysis. So is an identifiable team that maintains the principal interface and earns transaction revenue.
Include alternative access paths and their real usage. If users can call a contract directly, determine whether the commercial service still provides a materially different route or feature. If governance controls changes, document voting concentration, delegation, proposal rights, and execution. If privileges have been renounced, preserve evidence and the date. The assessment should explain the current and historical operating state because roles can change as a project decentralizes or adds managed services.
Separate federal analysis from state and other regimes
A federal Bank Secrecy Act analysis does not resolve state money-transmitter licensing or other federal regimes. Build a workstream matrix that lists the question, responsible counsel, jurisdictions, facts required, and status. State laws and exemptions can differ, and a product offered nationwide may need a coordinated licensing analysis. Similarly, an asset or activity may raise securities, commodities, banking, consumer, sanctions, or tax issues that use different definitions and tests.
Product decisions should not wait for a single all-purpose memo. Use issue-specific gates: which features can launch, where, for which users, under which limits, and with which controls. Maintain assumptions and conditions. For example, a conclusion may depend on no fiat handling, no custody, no discretionary routing, or no transaction fee. If engineering changes one of those facts, the decision should automatically return for review. This keeps legal analysis connected to production behavior.
Create an evidence package counsel can reproduce
Provide architecture and transaction diagrams, source and deployment information, key and permission inventories, contracts, terms, fee flows, user communications, governance records, and demonstrations of the live product. Include a fact table that answers who, what, when, where, for whom, and for compensation. Mark open questions and conflicting evidence. Do not ask counsel to infer control from a slide that omits relayers, recovery, or administrative paths.
Version the package and assign change triggers. New assets, chains, fees, APIs, institutional features, recovery methods, administrators, or routing services can alter the analysis. Preserve prior versions for historical activity. FinCEN’s 2019 guidance is a central primary source for understanding how its regulations apply to several convertible virtual-currency business models and provides the starting point for a fact-specific review:
Conclusion
The most useful U.S. function test is a disciplined description of the business model. It separates product paths, shows how value and instructions move, identifies every operating role, and records the technical and commercial facts that legal definitions must be applied to.
A label such as decentralized, self-custodial, or software-only may summarize one feature, but it should never replace the underlying evidence. Keep the evidence package synchronized with production, and route material changes back through legal and compliance review before they become assumptions embedded in the product.