# Contract Drafting Crypto > SKILL: Contract Drafting for Crypto Platforms - Skill: `nickgallick/contract-drafting-crypto` (Agent Skill) - Install (CLI): `npx skillmds@latest add nickgallick/contract-drafting-crypto` - Raw SKILL.md: https://api.skillmd.com/api/skills/nickgallick/contract-drafting-crypto/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: nickgallick (https://skillmd.com/u/nickgallick) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/nickgallick/contract-drafting-crypto --- # SKILL: Contract Drafting for Crypto Platforms **Version:** 1.0.0 | **Domain:** Smart Contracts, Legal Agreements, Token Grants, Investment Docs --- ## Ricardian Contracts — Legal + Smart Contract Hybrid **Concept:** A human-readable legal agreement that references a specific smart contract by address. The legal agreement governs INTENT; the smart contract governs EXECUTION. If the smart contract has a bug that contradicts the legal agreement → the legal agreement controls in court. ### Template Structure: ``` AGENT SPARTA CONTEST AGREEMENT Effective upon submission of transaction to smart contract at: [0x...] Network: [Ethereum/Base/Solana] RECITALS This Agreement governs participation in [Contest Name] facilitated by the smart contract deployed at [0x...] (the "Contest Contract"). By submitting a transaction to the Contest Contract, you agree to be bound by this Agreement. DEFINITIONS "Entry Fee" means the USDC amount sent to the enter() function of the Contest Contract. "Prize Pool" means the aggregate of all Entry Fees deposited in the current Contest round. "Platform Fee" means [X]% of the Prize Pool automatically distributed to [Perlantir address]. "Winner" means the address designated by the resolveContest() function call. CONTEST RULES The Contest is a skill-based competition as defined under Iowa Code §99B.5. Outcomes are determined by the measurable performance of AI agents configured by participants. The scoring methodology is published at [URL] and incorporated herein. DISPUTE RESOLUTION If the Contest Contract behaves inconsistently with this Agreement due to a bug, hack, or oracle failure: disputes shall be resolved by binding arbitration administered by JAMS under its Consumer Arbitration Rules. The human-readable terms of this Agreement shall control over any unintended smart contract behavior. GOVERNING LAW Delaware law governs this Agreement. [Arbitration venue: [City], Delaware] RISK DISCLOSURES Smart contract risk: [standard risk language] Blockchain network risk: [standard risk language] ``` --- ## Token Grant Agreements ### For Team Members and Advisors **Core provisions:** **1. Vesting Schedule** ``` Tokens vest over 48 months (4 years) from the Grant Date. Cliff: No tokens vest during the first 12 months. After the Cliff: 25% of the Total Grant vests. Thereafter: Remaining tokens vest in equal monthly installments over the following 36 months. ``` **2. Acceleration Provisions** ``` Single-Trigger Acceleration: Upon a Change of Control (defined as acquisition of >50% of voting equity or substantially all assets), 100% of unvested tokens accelerate and become immediately vested. Double-Trigger Acceleration (preferred for employees): Upon a Change of Control AND the recipient's termination without Cause or resignation for Good Reason within 12 months following the Change of Control, 100% of unvested tokens accelerate. ``` *Double-trigger is preferred: single-trigger creates a perverse incentive where recipients benefit from a sale they might otherwise resist.* **3. Forfeiture on Termination** ``` Upon termination of the recipient's service relationship with Company for any reason: all unvested tokens are immediately forfeited and returned to the Company's token treasury without compensation. ``` **4. Lock-up Period** ``` Notwithstanding vesting, tokens may not be transferred, sold, or disposed of until the earlier of: (a) 12 months following the Token Generation Event (TGE), or (b) a date specified by the Company's board following registration or exemption qualification under applicable securities laws. ``` **5. Tax Election Notice — CRITICAL** ``` IMPORTANT NOTICE REGARDING SECTION 83(b) ELECTION If the tokens are subject to a substantial risk of forfeiture (including a vesting schedule), recipient may elect under Section 83(b) of the Internal Revenue Code to be taxed at the Grant Date rather than the vesting date(s). This election must be filed with the IRS within 30 DAYS of the Grant Date. FAILURE TO FILE THIS ELECTION WITHIN 30 DAYS IS IRREVOCABLE. Recipient acknowledges receipt of this notice and agrees to consult with their own tax advisor regarding the advisability of filing a Section 83(b) election. Company is not responsible for any failure by recipient to timely file the election. ``` **6. On-Chain Vesting Implementation** ``` Token vesting shall be enforced on-chain via a vesting smart contract at [address] (the "Vesting Contract"). The Vesting Contract automatically releases vested tokens according to the schedule above. Recipient's vesting balance in the Vesting Contract serves as the definitive record of vested tokens. ``` --- ## Investment Documents ### SAFE (Simple Agreement for Future Equity) **Authority:** Y Combinator standard SAFE (2023 version) — the industry default **What it is:** Investor gives money now; receives equity at the next priced round **No interest, no maturity date** — simpler than a convertible note **Key terms:** - **Valuation cap:** Maximum valuation at which the SAFE converts to equity - **Discount rate:** Percentage discount on the next round price (typically 10-25%) - **MFN clause:** If company issues a more favorable SAFE to another investor, this investor gets the same terms **Download:** YC's standard SAFE is freely available at ycombinator.com/documents **Legal review needed:** Yes, but YC SAFE is market standard — minimal negotiation ### SAFT (Simple Agreement for Future Tokens) **Authority:** Cooley LLP designed the original SAFT framework (2017) **What it is:** Investment contract sold to accredited investors; investor receives tokens when the network launches **Key provisions:** - Purchase price (in dollars or crypto) - Token delivery: number of tokens or formula for determining tokens at TGE - TGE deadline: if tokens not delivered by [date], investor gets their money back - Discount: percentage discount from public TGE price - Lock-up: tokens locked for [X] months after TGE before transferable **Securities law:** The SAFT itself IS a security (an investment contract). Must be sold under Reg D 506(b) (no general solicitation, accredited investors only) or Reg D 506(c) (general solicitation allowed, all investors must be verified accredited). **Key risk:** If the token itself turns out to be a security (fails the Howey analysis post-TGE), you've sold securities twice: once the SAFT, once the token. Double exposure. This is why Howey analysis BEFORE any SAFT issuance is essential. ### Token Warrant **What it is:** Right to purchase tokens at a fixed price in the future (similar to a stock warrant) **Typically used:** For strategic partners, advisors, or early investors as a sweetener **Tax treatment:** More complex than direct token grants; consult tax counsel --- ## Smart Contract Audit Checklist (Legal Perspective) Before deploying any smart contract that holds user funds: **Functional review:** - [ ] Does the contract implement the rules exactly as described in the Ricardian contract? - [ ] Is there any admin function that allows withdrawal of user funds? (If yes: this is custodial) - [ ] What happens if the oracle fails or returns a bad value? (Define fallback in legal agreement) - [ ] Can the contract be paused? By whom? Under what conditions? - [ ] Can the contract be upgraded? (Upgradeable proxies = admin retains control = custodial argument) **Security review (Trail of Bits / OpenZeppelin / Certik):** - [ ] Reentrancy vulnerabilities - [ ] Integer overflow/underflow - [ ] Access control (who can call privileged functions?) - [ ] Oracle manipulation vectors - [ ] Front-running vulnerabilities **Legal characterization review:** - [ ] Does the contract's admin key architecture support the non-custodial argument? - [ ] Is the admin key multisig? Who holds keys? (Document this) - [ ] Is there a timelock on admin functions? (Strengthens decentralization argument) - [ ] Is the source code published and verified? (If yes: anyone can verify your non-custodial claim) --- *This is legal research and intelligence, not legal advice. Consult qualified legal counsel before taking action.*