Control is one of the most important and most misunderstood facts in a decentralized-finance assessment. Teams often point to a single feature—non-custodial settlement, token voting, immutable contracts, or a distributed contributor base—as proof that nobody controls the service. Reviewers make the opposite mistake when they treat any admin key or website as conclusive. Both shortcuts fail because decentralized products are layered systems. Control over one layer may be absent, shared, conditional, or strong while another layer has a different operator and risk profile.
A useful test therefore asks who can influence specific outcomes. Can someone change execution, restrict access, select assets, direct routing, collect fees, pause activity, communicate with users, or recover from failure? Is that power formal, practical, or merely theoretical? This guide organizes the inquiry into seven layers and shows how to record the evidence. It is designed for product reviews and governance discussions, not as a substitute for applying the law of a particular jurisdiction.
Layer one: smart-contract authority
Begin with the deployed contracts. Identify every proxy, upgrade mechanism, pause function, guardian, role, timelock, allowlist, oracle setter, fee setter, and emergency path. Record the addresses that hold those permissions and the entities or people who can use them. Do not stop at the nominal owner address. Trace whether it is a multisig, a governor contract, a module, or a key controlled by an infrastructure provider. Document signature thresholds, signer replacement procedures, hardware protections, and any social process required before a transaction is submitted.
Then test the practical reach of each permission. An upgrade key that can replace core logic is different from a guardian that can only pause a narrow component. A timelock may improve transparency but still preserve control. Renouncing one role may not matter if an oracle, router, or registry can redirect behavior. Review deployment scripts and verified bytecode rather than relying only on documentation. The result should be a permission matrix that describes what each role can cause, how quickly it can act, and what independent checks constrain it.
Layer two: the user interface and routing path
The most widely used website or app can shape a decentralized service even when it does not custody assets. An interface may determine default tokens, slippage, routes, warnings, blocked addresses, chain availability, or fee disclosures. It may inject a transaction, call a proprietary API, or select an aggregator before the user signs. Those choices affect what service the user actually receives. Capture the complete front-end flow, including remote configuration, content-delivery networks, analytics, wallet connectors, and any server component that prepares or simulates transactions.
Ownership and deployment matter. Record who controls the domain, source repository, build pipeline, hosting account, DNS, and release credentials. Determine whether alternative interfaces are genuinely usable or whether one operator dominates access and support. Also separate a neutral explorer from a transactional interface. A page that merely displays public data has a different role from one that curates assets, calculates a route, and presents a final transaction for signature. Interface analysis should reflect the exact product behavior instead of assuming that non-custody equals non-involvement.
Layer three: governance and concentrated influence
Token voting can distribute authority, but it can also obscure concentration. Analyze circulating and delegated voting power, quorum rules, proposal thresholds, veto rights, delegation platforms, and participation history. Identify founders, investors, foundations, delegates, service providers, and treasuries with material voting influence. Look for recurring coalitions and low-turnout conditions in which a small group can decide outcomes. Governance power should be measured over time because a nominally broad distribution can become concentrated through delegation or voter inactivity.
Formal votes are only part of governance. Many decisions are shaped before a proposal appears through working groups, forums, private calls, code authorship, and control of the proposal pipeline. Map who drafts specifications, funds development, decides what is technically feasible, and communicates the recommended outcome. A community may be free to vote against a proposal while lacking a realistic alternative implementation. Record these practical dependencies without automatically treating influence as legal control. The purpose is to show how decisions are actually made and where accountability resides.
Layer four: operations and incident response
Daily operations reveal control that static diagrams miss. Identify who monitors contracts, investigates alerts, maintains blocklists, coordinates with security researchers, publishes status updates, and decides whether an incident requires a pause. Review runbooks and actual incident history. A protocol may claim that nobody operates it while a standing team continuously watches activity and directs emergency actions. That team’s role may be necessary and beneficial, but it belongs in the scope analysis.
Examine dependencies on relayers, keepers, sequencers, validators, price feeds, hosted nodes, key-management systems, and proprietary databases. Determine whether the service degrades, stops, or changes materially if a named operator withdraws. Also record who can restore normal operation and whether users have an independent path to exit. Operational resilience and regulatory perimeter analysis share the same factual foundation: both require an honest account of essential people, systems, and permissions.
Layer five: commercial power and revenue
Follow the money from transaction to recipient. Protocol fees, front-end fees, spreads, priority fees, listing payments, referral revenue, rebates, token incentives, and treasury grants can connect an operator to the service. Identify who sets each economic parameter, who can waive or change it, and who benefits. A fee switch that has never been activated may still be relevant if governance can turn it on. Conversely, holding a token that may appreciate is not the same as receiving transaction-linked compensation for operating a service.
Commercial relationships can create additional control points. Market-making agreements, liquidity programs, bridge integrations, token-listing arrangements, and white-label deployments may impose obligations or grant influence. Review contracts and side letters, not just on-chain payments. Determine whether an entity promises availability, performance, support, or transaction processing to a partner. These commitments may show that the entity is doing more than contributing open-source code. Keep economic evidence connected to the specific function under review rather than treating revenue as a universal answer.
Layer six: communications and the user promise
Marketing language, documentation, and support channels help define the user relationship. Collect statements about who operates the service, what the product does, how fees work, and what users can expect during failure. Compare those statements with terms of use and technical reality. A project that promises a managed, optimized, secure transaction experience presents a different relationship from a repository that publishes code without offering a service. Neither description should be accepted without checking the facts.
Communication power is also operational power. Who can issue official warnings, recommend a migration, designate the canonical interface, or persuade users to avoid a compromised contract? Who controls social accounts, documentation, and brand assets? These channels can coordinate the community during normal operations and emergencies. Their existence does not by itself create VASP status, but it shows where trust and practical authority sit. Include them in the map so that the assessment reflects the product users actually encounter.
Layer seven: change over time
Control is a timeline, not a snapshot. A project may begin with founder-administered contracts, move to a multisig, add a timelock, transfer powers to a governor, and later introduce an emergency council. Interfaces and fee recipients may change independently. Build a chronology that links major releases to permission changes, entity formation, funding, and governance milestones. Preserve historical states because a current architecture does not erase how a service operated during an earlier period.
Define events that trigger reassessment: new privileged functions, signer changes, governance delegation, fee activation, a hosted relayer, new chain support, a bridge, a fiat connection, institutional APIs, or a major incident. Assign owners to maintain the permission matrix and evidence pack. The control analysis should be reviewed alongside the official risk-based framework and then tested against the law of each relevant jurisdiction:
Conclusion
A layer-by-layer test avoids two unhelpful extremes: declaring a project decentralized because users sign their own transactions, or declaring it centrally controlled because any administrator exists. The better question is who can influence each material outcome, through which mechanism, under what constraints, and for whose benefit.
Use the map as a shared artifact for engineering, security, governance, compliance, and legal teams. It will expose hidden dependencies, clarify accountability, improve incident planning, and provide better facts for perimeter analysis. Update it whenever the product or governance model changes.