01
Function map
Describe each service in verbs before applying a label.
Open reference →Independent decentralized VASP reference
Map decentralized control.
Design accountable services.
dVASP.com is a function-first field guide for understanding virtual-asset services across protocols, interfaces, entities, DAOs, wallets, and regulated operations.
10long-form implementation guides
6connected control workstreams
0token promotions or product endorsements
Working definition: “dVASP” is this site’s shorthand for analyzing decentralized virtual-asset service models. It is not a universal legal category, registration, license, or conclusion.
The function-first method
One map. Six connected workstreams.
Move from product facts to control, risk, architecture, and jurisdiction—without assuming that “decentralized,” “software,” or “non-custodial” ends the analysis.
02
Control map
Trace keys, interfaces, governance, fees, and practical influence.
Open reference →03
Risk model
Connect customer, geography, asset, product, and transaction risk.
Open reference →04
Travel Rule
Design data, counterparty, message, exception, and privacy workflows.
Open reference →05
Sanctions & security
Use accurate enforcement points, resilient data, and incident playbooks.
Open reference →06
Regulatory map
Separate global standards from binding jurisdiction-specific law.
Open reference →A repeatable review path
From architecture to accountable decisions.
Describe the service
Map user journeys, asset movement, counterparties, fees, and the service performed for others.
Identify people and control
Trace entities, administrators, keys, interfaces, governance, operational dependencies, and practical influence.
Apply risk and jurisdiction
Assess customers, assets, geographies, transactions, and the binding rules for each operating entity.
Design controls and evidence
Connect policy to real technical enforcement points, exception states, secure operations, and reproducible records.
The central question
Who can cause, prevent, shape, or profit from the service?
Control is layered. Smart contracts, front ends, governance, commercial arrangements, operations, and communications can have different owners and different consequences.
ProtocolUpgrade, pause, routing, parameters
InterfaceDefaults, access, lists, disclosures
GovernanceVotes, delegates, councils, vetoes
OperationsMonitoring, incidents, vendors, releases
Latest field notes
Practical guides for product and risk teams.
The Compliance-by-Design Stack for dVASP Products
Build compliance into a decentralized virtual-asset product through modular services, explicit decision points, strong evidence, and controlled change.
Read guide →
MiCA CASP vs. VASP: How the Terms Differ
Understand why VASP and CASP are not interchangeable labels and how to build a service-by-service EU perimeter map.
Read guide →
A Risk Framework for Self-Hosted Wallet Transactions
Build a risk-based workflow for deposits and withdrawals involving self-hosted wallets, smart contracts, and uncertain counterparties.
Read guide →Frequently asked questions
Clear boundaries before deeper analysis.
Is dVASP a formal legal category?
No. dVASP is a practical shorthand used by this site for examining decentralized virtual-asset service models. Legal classifications depend on the functions performed, the people and entities involved, control, location, and applicable law.
Does non-custodial always mean outside VASP scope?
No single architecture label decides the outcome. Non-custody is an important fact, but reviewers may also examine exchange, transfer, arrangement, interface, administrative, commercial, and governance functions.
What should a control map include?
At minimum: smart-contract permissions, interfaces, keys, governance, fees, entities, service providers, infrastructure, user relationships, incident powers, and evidence of how decisions are made.
Is this site legal or compliance advice?
No. It is an independent educational reference. Use qualified legal, compliance, security, and tax professionals for decisions about a particular product or jurisdiction.
Why combine compliance and security?
Controls depend on secure data, credentials, releases, vendors, logs, and incident response. A compliance rule cannot be effective if the system that enforces or records it is unreliable.