$1,000,000 in security audit grants are live now, Apply here →

← Resource Hub

Essential Managerial Efforts: Security Work After Launch

Updated 6 min read

Quick answer. Under SEC staff FAQ 2.3, once a crypto system is functional, services to secure, maintain, improve or enhance it would not involve essential managerial efforts. Who can ship a fix is a separate question under FAQ 1.5.

Watch: Essential Managerial Efforts: Security Work After Launch 1:36
Video transcript

SEC staff say that once a network is functional, paying for audits, fixes and monitoring generally does not create an investment contract. The harder question is who ships the fix.

FAQ 2.3 says services to secure, maintain, improve or enhance a functional crypto system, including funding development, are not essential managerial efforts.

On a plain reading, that covers audits, bug bounties, monitoring and incident response, and fixes with their testing. Counsel should confirm how it applies.

Two limits apply. Before functionality, the same services likely are essential managerial efforts. And FAQ 2.3 is staff guidance, not binding law.

If only the issuer's multisig can authorize an upgrade, that looks like unilateral authority to modify code, a central party power under FAQ 1.5. Route fixes through broad-based governance instead.

FAQ 1.5 has no emergency carve-out, so keep fast powers narrow: pause-only guardians, automatic expiry, timelocked upgrades and scoped pauses.

Governance approves the security budget and the foundation funds it. Auditors draft fixes. Governance applies them, and the arrangements are published.

Guardian runs the audits, monitoring and bug bounties the FAQ describes, and the fixes we draft ship through your governance. Read the full article, or talk to Guardian.

Essential managerial efforts are the efforts of others from which, under the Howey test, purchasers expect profit.

For issuers, the concept has a security edge. If promising to keep auditing, patching and monitoring kept a token tied to an investment contract, issuers would have a reason to stop paying for security.

FAQ 2.3 removes that reason for functional systems. It leaves a second question, added to the same page on November 2: who can actually apply a fix.

This article explains the technical and security side of SEC staff FAQ 2.3 and the Regulation Crypto Assets passage it cites. It is not legal advice; confirm how it applies to you with counsel.

FAQ 2.3 and the Passage It Cites

FAQ 2.3 asks which activities after functionality would not constitute essential managerial efforts.

Its answer cites the Regulation Crypto Assets proposing release, Release No. 33-11434 (August 18, 2026), at 91 FR 54525. The passage reads, in part, as follows.

Once such network or application is functional, it is our view that services to secure, maintain, improve, or enhance such a network ... would not constitute essential managerial efforts.

The elided text adds facilitating network effects, including by sponsoring or funding development projects. Promises by the issuer or another party to provide these services after functionality would not satisfy the Howey test.

The release reasons that, after functionality, the network's success or failure turns on many parties' contributions, not on these services.

It then draws the line. Before functionality, such services are provided or coordinated by the issuer and likely constitute essential managerial efforts.

Three status points matter:

  • The FAQ is staff guidance with no legal force or effect.
  • The cited view sits in a proposing release. Comments closed October 20, 2026. It has not been adopted.
  • Functional has a fixed meaning: the native asset can be used in accordance with the system's programmatic utility.

That definition comes from Section III of the March 17, 2026 interpretive release, per FAQ 2.3's footnote 5.

What the Services Cover

The text names categories, not tasks. Read plainly, they appear to cover a post-launch security program, though counsel should confirm:

  • independent audits of upgrades, new modules and new deployments;
  • bug bounties and audit contests;
  • monitoring, alerting and incident response;
  • fixes, client and dependency updates, and the testing behind them;
  • documentation, developer tooling and grants to outside teams.

The Canton Coin request letter of October 30, 2026 applied FAQ 2.3 this way. Because the network was functional at launch, it argued, ongoing development and ecosystem work would not be essential managerial efforts.

The staff's November 3 response relied on the letter's representations without commenting on that argument separately. See our Canton Coin explainer.

FAQ 2.3 does not cover what the issuer promised buyers when marketing the token. The interpretive release's examples include developing features and reaching roadmap milestones.

Under that release, the investment contract ends when those promises are fulfilled, or when purchasers could no longer reasonably expect them to be.

Under FAQ 2.2, the asset does not separate from the investment contract where another party assumes those promises. Our safe harbor post covers how to show they are complete.

Who Ships the Fix

FAQ 2.3 asks whether there is an investment contract. FAQ 1.5 asks whether the system has a central party.

A patch can be fine under the first and a problem under the second.

Take a critical bug in a lending market. Fixing it is maintenance.

But if the fix ships through an upgrade only the issuer's multisig can authorize, that looks like unilateral authority to modify the system's rules-based code.

FAQ 1.5's carve-out for discretion applies only where it is exercised solely through broad-based governance. So route fixes through that governance.

FAQ 2.4 (issuer statements) and FAQ 2.5 (buybacks) also depend on the system having no central party.

The design goal: separate the people who find and write fixes from the authority that applies them. Our central party explainer maps the four powers to code.

Emergency Powers That Stay Narrow

FAQ 1.5 has no emergency carve-out, so every fast power is one to inventory. Keep each one narrow.

  • Pause-only guardians. Compound's pause guardian can pause, but only the admin can unpause.
  • Automatic expiry. Optimism says a compromised Guardian could pause withdrawals for 3 months, then they automatically unpause.
  • Role sunsets. Give emergency roles an expiry date that governance must renew.
  • Timelocked upgrades. Put governance in front of a TimelockController as the only proposer.
  • Scoped pauses. Per-market or per-function flags limit an action to the affected path.
  • Governance review. Report every emergency action to governance, and let governance reverse it.

None of these removes a guardian from the analysis. They make it narrow enough for counsel to weigh whether it is material.

Funding Security Without Holding Control

The proposing release expressly includes sponsoring or funding development projects, so an issuer or foundation can keep paying for security. Structure it so money does not carry keys.

  1. Governance approves the security budget; the issuer or foundation funds it.
  2. Auditors and researchers draft fixes; governance applies them.
  3. Bounty payouts come from a governance-approved pool, under published rules.
  4. No vendor holds a contract role unless governance grants a narrow one.
  5. The arrangements are published, so stakeholders see who is paid to do what.

Monitoring needs no keys. Watching role grants, upgrades, multisig transactions and large movements is read-only.

Most incident response needs none either: simulating a pending transaction, alerting users, preparing a governance fix.

Only stopping or changing the system needs authority. If a monitoring vendor holds a pause role, list it like any other holder.

A Security Plan to Share With Counsel

  1. Functionality. The date, and evidence the native asset can be used in accordance with its programmatic utility.
  2. Promised efforts. What the issuer promised buyers, and each item's status.
  3. Security services. Who provides them, who pays and who approves the budget.
  4. Fix delivery path. Who can upgrade each contract, through which governance step, with what delay.
  5. Emergency powers. Holder, scope, unpause rule, expiry and how each use is reported.
  6. Vendor access. Any role held by an auditor, monitor, operator or relayer.
  7. Communications. Under FAQ 2.1, promoting current utility likely would not, without more, promise essential managerial efforts.
  8. Change log. Every role grant, upgrade and emergency action, with transaction hashes.

How Guardian Supports Security After Launch

Guardian runs security services of the kind FAQ 2.3 describes.

Managed Security monitors contracts on every block for privileged calls, role changes, upgrades, multisig transactions and large fund movements.

Its security operations team reviews every multisig transaction before it is signed. We also run bug bounty programs end to end, from hosting and triage to drafting a fix.

Vanguard includes post-launch update auditing. Fixes Guardian drafts can ship through your governance; your counsel owns the legal reading.

Frequently Asked Questions

Are audits and bug bounties essential managerial efforts after launch?

Under SEC staff FAQ 2.3, once a crypto system is functional, services to secure, maintain, improve or enhance it would not involve essential managerial efforts. On a plain reading, audits and bounties fall within that; counsel should confirm.

Does FAQ 2.3 apply before a network is functional?

No. The proposing release says that before functionality, such services are provided or coordinated by the issuer and likely constitute essential managerial efforts.

Can an issuer keep an upgrade key for emergency fixes?

FAQ 2.3 does not answer that. FAQ 1.5 lists unilateral authority to modify code as a central party power, with no emergency carve-out, so an issuer-held key is a fact for counsel.

Is FAQ 2.3 binding?

No. It is staff guidance with no legal force or effect. The view it cites appears in Release No. 33-11434, a proposed rule whose comment period closed on October 20, 2026.

Sources

Keep security running after the hand-off

Guardian monitors your contracts on every block, runs your bug bounty and reviews every update, while fixes ship through your governance.