SEC Staff Clarifies Who Controls a Crypto Network

Key Takeaways

• Unaffiliated voters generally aren’t treated as one group.
• Delegation and informal coordination still count.
• Unilateral access or code powers point to control.
• Working software and decentralization are separate tests.

The Division of Corporation Finance added questions 1.4 to 1.6 to its crypto asset FAQ on November 2, extending a page first published on September 25.

What Staff Added on November 2

Each new answer takes up one piece of the control test in the SEC’s March interpretation. That test turns on whether a “central party” (a person, entity or group with operational, economic or voting control) stands behind a crypto system. Question 1.4 asks when governance participants count as a group that could make up such a party. Question 1.5 explains what it means for a central party to oversee participation in a system. Question 1.6 separates a system that works from one that nobody controls.

The group answer comes with a stated boundary. It covers only digital-commodity classification under Section III of the interpretation and does not extend to other securities-law provisions dealing with groups, including the Exchange Act definition of an exchange.

Journalist Eleanor Terrett described the additions as an attempt to clarify decentralization questions that the CLARITY Act would address in law. The comparison also marks the limit. A statute binds; these answers reflect the views of Division staff, carry no legal force and were neither approved nor disapproved by the Commission.

Why the Central-Party Label Carries Weight

The SEC’s March 17 interpretation sorts crypto assets into categories that include digital commodities, collectibles, tools, stablecoins and digital securities. It treats a system as decentralized when it operates autonomously, free of control by a central party.

Staff tied that label to real consequences in its first batch of answers in September. Once a functional system has no central party, staff said, an issuer’s statements about it likely would not create a new investment contract, because no one holds the control needed to affect whether the system succeeds. The same batch confirmed that the interpretation’s definitions of “functional” and “decentralized” bear on how the Commission classifies assets.

Question 1.6 now pulls those two definitions apart. A system is functional when its native asset can be used according to its programmed utility. Decentralization asks something else: whether the system runs without anyone in control. Staff said functional systems associated with digital commodities show characteristics of decentralization, with the degree depending on the circumstances.

None of this assigns a status to a named token. The interpretation also separates an asset’s classification from the transactions around it, so an asset that is not itself a security can still be sold subject to an investment contract.

When Independent Voters Count as a Group

Under Question 1.4, participants in a functional system’s broad-based governance generally are not treated as a group if they are unaffiliated and have no separate agreement or understanding, formal or informal, to act together outside the governance process. Delegation falls within that review. The same approach applies when governance runs through a foundation or association and participation depends on holding the system’s native token.

That last point drew the quickest industry response. Miles Jennings of a16z crypto said the answer shows projects can use legal entities such as DUNAs, Wyoming’s decentralized unincorporated nonprofit associations, without giving up decentralized governance. The FAQ itself names no entity type.

Being a group is only the first step. A group must also hold operational, economic or voting control to meet the central-party definition. A footnote then describes the kind of governance staff has in mind. It should be transparent and rules-based, with diverse stakeholders contributing independently. Proposals, debate, votes and implementation should be open to the public, and authority should not be concentrated through affiliated participants or delegation.

Read together, the conditions cut both ways. Thousands of voting wallets show participation, not independence. If a handful of delegates carry most of the voting weight, or affiliated wallets vote as a bloc, the footnote’s warning about concentrated authority comes into play. In the other direction, broad support for a proposal is not evidence of a side deal. Voters who back a security patch after open debate are using the governance system as intended.

The on-chain record covers only part of this check. It shows how much voting power an address holds, not who controls the key or what that person agreed elsewhere, a gap that also runs through the debate over disclosing market-maker agreements.

Powers That Sit Outside the Vote

Question 1.5 lists what oversight looks like at the protocol, validator and user levels:

• granting or limiting access
• changing voting procedures
• deciding who validates transactions
• modifying code
• reversing transactions and revoking access

In each example, a central party can use the power on its own. The answer contrasts that with systems whose material operations run automatically under rules-based code. In those systems, any remaining discretion is exercised only through governance whose participants are not themselves a central party.

So the practical test is whether any of those powers has a route that skips the vote. Arbitrum offers a documented one. Its constitution lets a Security Council act in emergencies without waiting for token holders. On April 21, the council froze about 30,766 ETH held by the KelpDAO exploiter on Arbitrum One.

A freeze of that kind resembles the reversal and access powers in Question 1.5. The framework’s follow-up questions are who holds the signing keys, how independent those people are from one another and from any single organization, and what restrains them. The FAQ does not mention Arbitrum, and nothing in it indicates how staff would view this arrangement. Arbitrum does put the structure in writing; the independence of individual signers takes separate reporting.

Arbitrum’s Security Council, as documented

• Members: 12, chosen through elections set out in the ArbitrumDAO Constitution
• Emergency actions: 9 of 12 signatures, executed immediately and followed by a transparency report
• Routine upgrades: also 9 of 12, then routed through the delayed later phases of the proposal process
• Override: the DAO can curtail or remove emergency powers through a constitutional proposal

Source: Arbitrum DAO governance documentation

Smaller protocols rarely spell this out, so the answer often sits in their contracts. OpenZeppelin’s governance documentation warns that giving proposer or canceller roles on a timelock to anyone besides the governor lets that party bypass governance or stop approved actions. Spotting a Governor contract starts the check; every timelock role and every admin key on an upgradeable contract still needs an owner. A multisig threshold says how many signatures a change needs, and a timelock says how long users wait before it lands. Neither says how many independent people stand behind those signatures.

Suspected $106M Crypto Theft Ran Through Familiar Wallets

Which System the Power Reaches

A footnote to Question 1.5 adds a qualification that is easy to miss. A foundation or association that does not control a network could still control a separate crypto system, for instance by setting operating parameters for applications deployed on that network. A control finding therefore needs a precise target: the network, an application, a treasury, a token contract or a grants program.

Those targets carry different consequences. Coindoo’s September report on an Arbitrum proposal to ban alleged grant abusers from DAO funding concerned access to treasury money. Blocking someone from submitting transactions to the chain would be a different power entirely, and authority over one says nothing about authority over the other.

Checking a Decentralization Claim Yourself

The framework comes down to three questions: what power exists, who holds it and what restrains it. The records that answer them are usually public but scattered.

Where the answers usually sit

1

The power

Verified contract code and role assignments on a block explorer, including owner and proxy-admin addresses.

2

The holder

Multisig signer lists, council election results, delegate statements and affiliation disclosures on the project’s governance forum.

3

The restraint

Timelock lengths, the project’s constitution or charter, post-incident reports and any mechanism letting token holders remove the power.

Gaps in those records leave a decentralization claim unverified rather than disproved, and a clean result is no legal opinion on any token. A vote count shows how many people took part. Since November 2, the sharper question is who could act without them.