> For the complete documentation index, see [llms.txt](https://docs.metalex.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metalex.tech/building-on-the-protocol/reference/templates.md). # Agreement templates Reusable legal-instrument templates live in the [`/templates`](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/README.md) directory. Registration in `CyberAgreementRegistry` is per chain, so a template can exist on one chain and not another: the cyberSTOCK template below is registered on Ethereum and Base Sepolia but not on Base or Arbitrum. Call `getTemplateDetails(templateId)` on the target chain before relying on a template; it reverts `TemplateDoesNotExist` for an unregistered id. ## cyberSAFE | Template | Style | Filing path | | --------------------------------------------------------- | -------------------- | ------------------- | | `MetaLeX cyberSAFE US style Reg D v 1.0.md` | YC post-money | Reg D (US) | | `MetaLeX cyberSAFE UK Cayman style Reg S v 1.0.md` | YC post-money | Reg S (UK / Cayman) | | `MetaLeX cyberSAFE jx-neutral-style Reg D raise v 1.0.md` | Jurisdiction-neutral | Reg D (US) | | `MetaLeX cyberSAFE jx-neutral-style Reg S raise v 1.0.md` | Jurisdiction-neutral | Reg S | | `mlx_safe_reg_d_v1_3.md` / `mlx_safe_reg_s_v1_3.md` | v1.3 series | Reg D / Reg S | ## cyberSAFT | Template | Filing path | | --------------------------------------------------- | ----------- | | `MetaLeX cyberSAFT reg D v.1.0.md` | Reg D | | `MetaLeX cyberSAFT Reg S raise v 1.0.md` | Reg S | | `mlx_saft_reg_d_v1_3.md` / `mlx_saft_reg_s_v1_3.md` | v1.3 series | ## cyberSAFTE * `mlx_safte_reg_d_v1_3.md`: Reg D, v1.3. ## cyberSTOCK * `mlx_cyberstock_reg_d_v1_0.md`: a tokenized-share subscription agreement, Reg D, v1.0, with template id `bytes32(bytes("metalex_cyberstock_reg_d_v1_0"))`. ## cyberTokenWarrant | Template | Filing path | | ----------------------------------------------------------------------------- | ------------------------ | | `MetaLeX cyberTokenWarrant a16z US style reg D v 1.0.md` | a16z-derived, Reg D (US) | | `MetaLeX cyberTokenWarrant a16z jx-neutral-style-issuer Reg D raise v 1.0.md` | jx-neutral, Reg D | | `MetaLeX cyberTokenWarrant a16z-jx-neutral-style-issuer Reg S raise v 1.0.md` | jx-neutral, Reg S | | `MetaLeX cyberTokenWarrant non-US Reg S v 1.0.md` | Reg S | | `mlx_safe_tw_reg_d_v1_3.md` / `mlx_safe_tw_reg_s_v1_3.md` | v1.3 series | ## MetaDAO Futarchy Governance SPC * `MetaDAO Futarchy Governance SPC - Board Consent - Approval of SegCo v 1.0.md` * `MetaDAO Futarchy Governance SPC - SegCo combined v 1.0.md` ## LeXcheX agreement * `MetaLeX LeXCheX Agreement.md`, which a credential subject countersigns on receiving a LeXcheX credential. ## Custom templates Anyone can register a template with `CyberAgreementRegistry.createTemplate(templateId, title, legalContractUri, globalFields, partyFields)`. Template ids are caller-chosen `bytes32` values (by convention, `bytes32(bytes(""))`) and must be unused, and a template's fields cannot be overwritten once created. The directory also holds a combined cyberSAFE and cyberTokenWarrant template prepared for one issuer, as an example of a custom variant. Standalone agreements (`createStandaloneContractAndSign`) skip this step. The registry derives the template id from `keccak256(abi.encode(title, legalContractUri, globalFields, partyFields))` and registers the template on first use. The two `DEPRECATED-*` files in the directory (`SAFE-version-0-1`, `SAFEplusT-version-0-1`) are not for new agreements. ## LET legal release v1.4 These eight packets and eight standalone instruments are published on IPFS. Their CIDs and fetched bytes match the approved release manifest. Registration and full field readbacks are complete on Ethereum, Base and Arbitrum. Each packet combines the reusable cyberSPA with its Exhibit A instrument(s). The registry URI identifies that packet; each LET uses its matching standalone instrument URI. Existing v1.3 and custom templates remain unchanged. | Instrument | Reg D specification | Reg S specification | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | SAFE | [mlx\_safe\_reg\_d\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_reg_d_v1_4.md) | [mlx\_safe\_reg\_s\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_reg_s_v1_4.md) | | SAFE + Token Warrant | [mlx\_safe\_tw\_reg\_d\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_tw_reg_d_v1_4.md) | [mlx\_safe\_tw\_reg\_s\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_tw_reg_s_v1_4.md) | | SAFT | [mlx\_saft\_reg\_d\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_saft_reg_d_v1_4.md) | [mlx\_saft\_reg\_s\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_saft_reg_s_v1_4.md) | | SAFTE | [mlx\_safte\_reg\_d\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safte_reg_d_v1_4.md) | [mlx\_safte\_reg\_s\_v1\_4](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safte_reg_s_v1_4.md) | [Exact approved registration arguments](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/releases/let-v1.4.json) preserve predecessor field order and encoding. The release package includes offline CAR roots, PDF hashes and successful gateway verification receipts. The manifest records confirmed transactions and receipt blocks for all three chains. Testnets retain their existing templates. The release requires no existing-family core protocol change. SAFO integration and upgrades are a separate review; no SAFO registration is included in this release manifest. ## See also * [Sign a cyberAgreement](/building-on-the-protocol/how-to/sign-a-cyberagreement.md) * [`CyberAgreementRegistry`](/building-on-the-protocol/reference/contracts/cyberagreementregistry.md) ## cyberSAFO (published, not registered) * [Reg D v1.1](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safo_reg_d_v1_1.md) and [Reg S v1.1](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safo_reg_s_v1_1.md): native class 14 and the version-1 per-LET SAFO extension. Their PDFs are pinned and CID-verified in the [v1.1 release manifest](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/releases/safo-v1.1.json). Registry registration and activation require the separately approved compatible deployment. The v1.0 specifications are superseded and are not registration candidates. ## Blockchain notices legal release (October 18, 2026) The approved v1.5 existing-family packets and v1.1 SAFO packets add a common Blockchain Notices clause. Dark and light copies are pinned and CID-verified. Browser retrieval verified every PDF byte hash. Ethereum, Base and Arbitrum registrations for the eight existing-family templates are verified in the [registration readbacks](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/releases/let-v1.5-registrations.json). App release remains pending. SAFO registration and activation retain their separate runtime and review gates. Existing registrations retain their original text. * [mlx\_safe\_reg\_d\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_reg_d_v1_5.md) * [mlx\_safe\_tw\_reg\_d\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_tw_reg_d_v1_5.md) * [mlx\_saft\_reg\_d\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_saft_reg_d_v1_5.md) * [mlx\_safte\_reg\_d\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safte_reg_d_v1_5.md) * [mlx\_safe\_reg\_s\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_reg_s_v1_5.md) * [mlx\_safe\_tw\_reg\_s\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safe_tw_reg_s_v1_5.md) * [mlx\_saft\_reg\_s\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_saft_reg_s_v1_5.md) * [mlx\_safte\_reg\_s\_v1\_5](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safte_reg_s_v1_5.md) * [mlx\_safo\_reg\_d\_v1\_1](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safo_reg_d_v1_1.md) * [mlx\_safo\_reg\_s\_v1\_1](https://github.com/MetaLex-Tech/cybercorps-contracts/tree/develop/templates/mlx_safo_reg_s_v1_1.md) SAFO also requires its separate runtime and independent review gates. The notices clause requires no contract implementation change. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.metalex.tech/building-on-the-protocol/reference/templates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.