The phrase decentralized VASP sounds like a contradiction. A virtual asset service provider is usually understood as a person or organization performing covered financial functions for others, while a decentralized protocol may be presented as software with no operator. In practice, many projects sit between those poles. A protocol may be non-custodial yet have a controlled interface, a fee switch, an upgrade key, a treasury, a governance council, or a team that coordinates listings and incident response. dVASP.com uses “dVASP” as a working shorthand for examining that middle ground. It is not a claim that every decentralized application is a VASP, and it is not a substitute for jurisdiction-specific legal analysis.
Assess conduct, not slogans: service, customer, control, execution, access, pricing, upgrades, custody, settlement, and the user relationship. This guide turns those facts into a repeatable review map.
Start with the service function
The first step is to describe the product in verbs. Does it exchange one virtual asset for another, transfer assets, safeguard keys or assets, arrange transactions, operate an order-routing layer, or support an issuance or sale? Avoid beginning with architecture labels such as decentralized, peer-to-peer, automated, or non-custodial. Those labels can be relevant facts, but they do not identify the economic service. A protocol can be automated while a team actively maintains the user-facing path. A service can be non-custodial while still bringing counterparties together or controlling material transaction parameters. A function map should list each user journey, the asset movement it enables, the parties involved, and the point at which a person or coordinated group contributes to the activity.
Next, separate software capabilities from services performed for or on behalf of another person. Publishing general-purpose code is different from operating a branded gateway, selecting supported assets, charging transaction-based fees, resolving failed transactions, or maintaining a privileged router. The analysis should record who performs each step and what would happen if that participant stopped. This produces a factual service inventory that can be compared with applicable definitions. The inventory should be updated whenever the product adds a chain, wallet connector, liquidity source, bridge, fiat rail, embedded swap, institutional API, or managed recovery feature, because apparently small product changes can alter the function profile.
Map people, entities, and coordinated groups
Decentralized systems still depend on people. A complete map identifies the development company, foundation, DAO delegates, multisig signers, interface operator, domain owner, infrastructure providers, market makers, fee recipients, customer-support team, and any administrator with emergency authority. The purpose is not to assume that every contributor is a regulated provider. It is to understand whether one participant, several participants acting together, or an identifiable entity performs a covered function. Contracts, employment relationships, grant agreements, revenue shares, and operational playbooks can show coordination that a governance forum alone does not reveal.
Document decision rights as carefully as job titles. Who can approve a release, pause a contract, alter fees, change a price oracle, add a token, modify geographic restrictions, or restore service after an incident? Who possesses the credentials for cloud accounts, analytics, front-end deployment, signing services, and treasury wallets? A project may describe governance as dispersed while a small operations group retains practical control through access, expertise, or urgency. The map should also show dependencies outside the core protocol, because an interface company or hosted routing service may have a distinct role even when the underlying contracts are immutable.
Test control in layers
Control is rarely binary. Analyze it in layers: protocol control, interface control, commercial control, governance control, and operational control. Protocol control includes upgradeability, pausing, parameter changes, allowlists, routing logic, and admin keys. Interface control includes the website, API, default pathways, wallet prompts, token lists, disclosures, and geofencing. Commercial control includes fees, rebates, incentives, treasury allocation, and contractual relationships. Governance control includes proposal rights, voting concentration, delegation, vetoes, and emergency committees. Operational control includes monitoring, incident response, communications, and the ability to coordinate third parties.
The resulting picture may show different conclusions for different layers. An immutable contract may be outside one perimeter while a separately operated interface performs activities that require analysis. A DAO may have broad token voting but delegate daily decisions to a foundation. A team may lack unilateral voting power yet remain indispensable because it controls repositories, release tooling, or the only widely used interface. Record both formal authority and practical influence. The aim is not to force every fact into a single control score; it is to identify who can cause, prevent, shape, or profit from the relevant service.
Follow the value and the user relationship
Economics often clarify operating roles. Trace every fee from the user transaction to its final recipient, including protocol fees, interface fees, spreads, referral payments, validator incentives, token emissions, and treasury distributions. Determine who sets the fee, who can change it, and whether revenue depends on transaction volume. Transaction-linked compensation does not automatically determine regulatory status, but it can demonstrate that an identifiable participant is operating or promoting a service rather than merely publishing neutral software. Grants and token allocations should be included when they fund continuing product operations.
Also map the user relationship. Who markets the product, writes the terms, answers support requests, posts risk notices, handles complaints, and decides which users or jurisdictions may access the interface? A project may claim that users interact only with code while simultaneously presenting a branded service with curated routes and ongoing support. That tension is analytically important. Capture the representations made to users because they help explain what the project believes it provides. Compare those representations with the technical flow and contractual structure; inconsistencies are a signal to investigate, not a reason to choose the most convenient description.
Treat jurisdiction as a separate workstream
There is no single global dVASP license or universal DeFi exemption. FATF standards influence national approaches, but laws, definitions, thresholds, licensing processes, and enforcement practices differ. A project should build a jurisdiction matrix based on incorporation, team location, governance participants, infrastructure, target markets, user residence, asset availability, marketing, and any fiat or banking connections. The matrix should distinguish global standard-setting material from binding local law. It should also identify where counsel is needed rather than turning a high-level comparison into a legal conclusion.
Prioritization matters. Start with jurisdictions that have the strongest operational nexus or largest user exposure, then examine locations associated with key entities and decision makers. Consider whether the service is actively offered into a market, merely reachable from it, or specifically restricted. Record the evidence for each assumption and the date it was reviewed. Because regulatory frameworks evolve, the matrix should have named owners, a review cadence, and change triggers such as a new token, marketing campaign, interface language, local partner, or payment rail.
Build a defensible evidence pack
A good perimeter assessment is reproducible. Keep architecture diagrams, transaction-flow descriptions, screenshots, governance documents, key-management records, fee tables, contracts, token-allocation schedules, repository permissions, and interview notes. Link each conclusion to specific evidence and identify uncertainty. Where facts conflict, record the conflict rather than smoothing it over. For example, governance documentation may say that no administrator exists while deployment records show an upgrade path controlled by a multisig. The discrepancy should become an action item with an owner and deadline.
Use versioning. A conclusion about release 1.0 may not remain accurate after the team adds a hosted relayer or delegates control to a new council. Store the assessment with the product version, chain, interface, and date. Maintain a decision log for material design choices, including why a control was added or removed. This evidence supports legal review, audit, partner diligence, and internal governance. It also prevents institutional memory from disappearing when contributors change. The goal is not to produce a document that proves a preferred answer; it is to create a record that allows an informed reviewer to reach a reasoned answer.
Turn classification questions into design decisions
Perimeter work is most valuable before launch. If a team understands which features create control, intermediation, or a continuing service relationship, it can decide deliberately how the product should operate. That does not mean designing around obligations. It means choosing an accountable architecture and matching controls to the actual role. A team may decide to operate a regulated service, reduce unnecessary privileges, separate an interface from protocol governance, impose stronger onboarding for a managed feature, or abandon a feature whose risk cannot be managed. Each choice should be reviewed for substance rather than appearance.
Product, engineering, legal, compliance, security, and governance teams should review the same map. Engineers can confirm what keys and contracts can do; product owners can explain user journeys; finance can trace revenue; security can identify operational dependencies; and legal counsel can apply the relevant definitions. Cross-functional review is especially important for decentralized systems because no single team sees every layer. Use the official source as a baseline for terminology and risk-based expectations, then apply local law with qualified advice:
Conclusion
A decentralized VASP assessment is not solved by asking whether a protocol is decentralized enough. It is solved by identifying the service, the people and entities behind each layer, the control mechanisms, the economics, the user relationship, and the jurisdictions involved. dVASP is therefore best used as an investigation prompt rather than a legal label.
Keep the analysis factual, versioned, and tied to evidence. Revisit it when governance, fees, interfaces, chains, assets, or operational roles change. That discipline gives decision makers a clearer basis for product design, licensing analysis, risk treatment, and transparent communication with partners and users.