º£½ÇºÚÁÏ

This post uses hypothetical scenarios for illustrative purposes only. It does not describe any actual client, transaction, or representation, and is not legal advice.

Download: Crypto Executive Employment Agreement Checklist (.docx) — a companion resource for this post. Adapt with counsel before use.

Consider a hypothetical high-growth crypto company that has just closed a Series B, hired a former exchange executive to run business development, and pushed a standard 20-page executive employment agreement across the table. Base salary, equity grant, non-compete, IP assignment, at-will termination, garden-variety confidentiality — the same template the general counsel used at the founders’ last SaaS company. Nine months later, the executive leaves for a competitor with an on-chain protocol build that overlaps 60% of the departing company’s codebase. The company reaches for the non-compete and discovers it is unenforceable against a fully-remote foreign competitor, the IP assignment does not cleanly reach a forked repository, and the departing executive still holds a large tranche of vested tokens that are neither locked nor restricted. Every one of those failures traces back to the moment someone reused a SaaS template for a crypto company hire. The template is where the value leaks.

Here are the five places a standard executive employment agreement fails for a high-growth crypto company, and what the drafting has to do differently.

First — the compensation description

A crypto executive’s comp package is not “cash plus equity.” It is cash plus equity plus a token allocation, and each of the three needs its own vesting schedule, acceleration language, and forfeiture mechanics. The template failure is folding all three into one clause with one vesting schedule and one acceleration trigger.

The cash component is straightforward — salary, bonus, standard withholding. The equity component follows the company’s equity-incentive plan, usually with a 4-year vest and a 1-year cliff, and acceleration on double-trigger change-in-control. The token component is where the drafting has to think. Token grants can be structured as restricted token units (analogous to RSUs), token options (with a strike price), or direct grants of already-issued tokens subject to a vesting overlay. Each has different tax posture, different SEC posture, and different community-optics implications at TGE.

The compensation clause should specify (a) the total token allocation, (b) whether it counts against the company’s employee token pool or is issued separately, (c) the vesting schedule and cliff, (d) whether the tokens are transferable during vesting, (e) the acceleration triggers, and (f) the interaction with any founder-side token vesting schedule the company has published. The interaction with our founder token vesting note is direct — the executive’s token schedule should not be more favorable than the founders’ on any dimension that the community will see.

Second — IP assignment that reaches the on-chain artifacts

The template IP assignment says the executive assigns to the company “all inventions, discoveries, and works of authorship” made in the scope of employment. That language was drafted for a world of proprietary source code stored in a private repository. It does not cleanly reach five categories of artifact that a crypto executive creates every week.

The first is on-chain contract code — smart contracts deployed to a public network, where the “work” exists as bytecode at a specific address as well as a source repository. The assignment should reference both. The second is protocol governance artifacts — proposals, parameter recommendations, technical specifications published to community forums under the executive’s own name or a pseudonym. The third is community-facing materials — blog posts, technical papers, ecosystem-grant proposals — that carry the company’s reputational weight even when they read as the executive’s personal work. The fourth is forks and derivatives — where the executive contributes to an open-source project that draws on the company’s codebase, and the assignment needs to be clear about which direction the ownership runs. The fifth is off-chain infrastructure — nodes, monitoring tools, indexers, and dashboards — that are often treated as personal projects but that create real IP the company later relies on.

A well-drafted crypto IP assignment expands the definition of “invention” to include on-chain code, protocol artifacts, and community-facing works, and includes a specific mechanic for handling contributions to open-source projects that intersect with the company’s work. The assignment also has to be careful with contributor-license-agreement obligations that the company itself has undertaken to upstream projects.

Third — confidentiality extended to on-chain data

The confidentiality clause in a standard employment agreement covers “trade secrets and confidential information.” In a crypto company, the drafting has to reach several categories of information that are not intuitive.

Testnet activity — the addresses, contracts, and behavior patterns the company runs on a public testnet — is often more sensitive than mainnet activity because it reveals the direction of unreleased work. Treasury balances and address associations — the wallets the company controls, the multisig signers, the flow of tokens between the company and the foundation — are commercially sensitive even where the underlying blockchain data is public, because linking public addresses to a specific entity is a real disclosure. Unpublished protocol upgrades — the code, the timing, the parameter changes contemplated — are market-moving information. Node infrastructure and validator-set information — who runs what, on which cloud, with what security posture — is both operationally sensitive and adversarially useful.

The confidentiality clause should enumerate these categories explicitly rather than rely on the residual “confidential information” definition. It should also address a fact pattern the SaaS template does not contemplate — the executive’s personal on-chain presence. Executives at high-profile crypto companies routinely have personal wallets, personal governance participations, and personal on-chain identities that are known to the community. The agreement should not force the executive to keep those private (which is unenforceable), but it should require the executive to disclose material overlaps with the company’s business and abstain from on-chain actions that create a conflict.

Fourth — the non-compete that actually restricts something

The standard 12-month geographic non-compete — the one every SaaS company uses, drafted around a defined territory and a defined industry — is essentially toothless against a crypto competitor. Crypto protocols are borderless. A competitor building an on-chain product is not “located” anywhere in a way that a geographic covenant captures. And the FTC’s April 2024 non-compete rule, though enjoined and unlikely to survive in its original form, has permanently changed the boardroom conversation about how enforceable any non-compete will be.

Florida remains one of the more employer-friendly non-compete jurisdictions in 2026, and Fla. Stat. § 542.335 continues to authorize enforceable non-competes supported by a legitimate business interest. Florida’s CHOICE Act, effective July 1, 2025, further expanded the enforceable window for “covered employees” earning above a defined threshold. But even under CHOICE, the covenant needs to be structured around what actually restricts a departed crypto exec.

Two mechanics do real work. The first is a narrowly-drafted product-and-role-scoped non-compete — the exec cannot, for a defined period, take a role at any organization whose product substantially overlaps with a defined product category, regardless of geography. This survives Florida’s reasonableness analysis better than a geographic covenant that everyone knows is unenforceable in practice. The second is a token-based restriction that operates outside employment-covenant law entirely — the exec’s unvested tokens are forfeited on any competitive engagement, and a portion of the vested tokens are subject to a claw-back on a defined competitive-activity trigger. The claw-back is a contract-remedy question, not an employment-covenant question, and it works where a covenant does not.

The non-solicit is a separate lever. For crypto companies, the meaningful non-solicit reaches not only employees and customers but also validators, grant recipients, and named ecosystem partners — categories that the SaaS template does not name and that a court will not read in without specific language.

Fifth — termination, separation, and the token interaction

Termination provisions in a crypto executive agreement carry more moving pieces than any other section. The interaction between vested tokens, unvested tokens, lockups, and continuing obligations has to be mapped explicitly.

Vested tokens are the executive’s property. The agreement can subject them to a post-termination lockup — 6 or 12 months, aligned with the founder lockup — but cannot generally forfeit them absent a defined for-cause trigger. Unvested tokens are the company’s to reclaim on termination, with the standard question being whether the termination is for cause (full forfeiture) or without cause (partial acceleration, typically 6 to 12 months of additional vesting). Lockups on vested tokens continue to run after termination — the schedule does not accelerate on separation.

The claw-back mechanic sits alongside the forfeiture mechanic. Forfeiture reaches unvested tokens the executive has not earned. Claw-back reaches vested tokens the executive has earned but engaged in defined post-termination conduct — competitive activity, breach of confidentiality, breach of non-solicit — that triggers a return. Claw-back is enforceable, but only where the contract clearly defines the trigger, the amount, and the mechanism of return. Courts are more willing to enforce claw-back where the tokens have moved into an escrow or a multisig with a claw-back key than where the company is chasing tokens the executive already transferred to a personal wallet or an exchange.

Continuing obligations — confidentiality, IP assignment tail, non-solicit, non-disparagement — should be pinned to defined durations that survive termination. The template failure is language like “in perpetuity” or “for so long as the information remains confidential,” which is aspirational rather than enforceable. A well-drafted crypto agreement uses defined survival periods — typically 12 to 24 months for non-solicit, indefinite for trade-secret confidentiality, and a defined tail for IP assignment covering post-termination inventions in the company’s field.

Where the industry practice has landed

Post-2024, the market has consolidated around a set of drafting norms that were not standard three years ago. Token comp is disclosed on a schedule attached to the agreement. IP assignment reaches on-chain artifacts explicitly. Confidentiality enumerates on-chain data categories. Non-competes are drafted narrowly on product-and-role and paired with token claw-back. Termination provisions distinguish vested / unvested / locked / unlocked and address each combination. Where the SaaS template says “standard,” the crypto agreement now says “specific.”

The underlying dynamic is that a crypto executive holds a category of value — token comp — that a SaaS executive does not, and that value sits on a public ledger where every transfer, every vote, and every wallet association is visible. The agreement has to be drafted for that visibility.

Download: Crypto Executive Employment Agreement Checklist (.docx) — a companion resource for this post. Adapt with counsel before use.

For related structural background, see our notes on founder token vesting, SAFT / T-SAFE / token warrant instrument choice, and Florida’s CHOICE Act framework in garden leave and key-employee retention. The full text of Florida’s non-compete statute is available at .

If you are negotiating an executive employment agreement for a high-growth crypto company, feel free to reach out to our firm manager, Magda, at Magda@montague.law, or fill out our contact form. Mention you read this post.