The useful question is not “Is this decentralized?” It is “What service is performed, for whom, by which people or entities, through which controls, and in which jurisdictions?”
Begin with the function
Describe the product in verbs: exchange, transfer, safeguard, route, match, execute, arrange, issue, redeem, administer, or provide access. Then draw each user journey from instruction through settlement. Include contracts, addresses, relayers, APIs, fiat rails, interfaces, and service providers. A product may contain several distinct services, and each can have a different operator or perimeter.
Architecture labels are supporting facts. Non-custodial design can reduce or change certain risks, but it does not describe every activity. Automation can make execution predictable while an identifiable team still controls the principal interface, fees, asset list, upgrades, or incident response. “DAO” can describe governance while a foundation or contractor performs daily operations.
Identify people, entities, and coordinated groups
Map the development company, foundation, multisig signers, delegates, interface operator, domain owner, support team, treasury recipients, market makers, and infrastructure providers. Record contracts, grants, employment, revenue shares, and working relationships. The purpose is not to assign status by association; it is to understand who performs each part of the service.
- Who owns the domain, repository, deployment pipeline, and production credentials?
- Who can change contract logic, parameters, fees, routes, or supported assets?
- Who communicates with users, handles incidents, and designates the canonical release?
- Who receives transaction-linked revenue or promises service availability?
Test control in layers
| Layer | Questions | Evidence |
|---|---|---|
| Protocol | Can logic, pausing, or parameters change? | Bytecode, roles, proxies, timelocks, signer records |
| Interface | Who selects defaults, routes, assets, and access? | Source, configuration, domain and deployment access |
| Governance | Who proposes, votes, delegates, vetoes, and executes? | Voting data, charters, delegation and execution history |
| Commercial | Who sets fees, incentives, and partner terms? | Contracts, fee flows, treasury and revenue records |
| Operations | Who monitors, supports, responds, and restores? | Runbooks, access logs, incidents, vendor agreements |
Add jurisdiction after the facts
Global standards influence national frameworks, but they are not a single worldwide license. Build a jurisdiction matrix based on operating entities, team and governance location, target markets, users, marketing, infrastructure, assets, and banking or payment links. Separate a standard-setter’s terminology from binding local law, regulatory guidance, and supervisory practice.
Every conclusion should state its scope, evidence, assumptions, uncertainty, and review date. A decision that depends on no custody, no fiat, no discretionary routing, or no transaction fee must return for review when that fact changes.
The five outputs of a useful dVASP review
- Service map: user journeys and asset movement.
- Responsibility map: entities, people, governance, and providers.
- Control map: formal permissions and practical influence.
- Risk map: customer, asset, geography, transaction, technology, and counterparty risk.
- Jurisdiction map: the specific legal questions and owners for each market.