> For the complete documentation index, see [llms.txt](https://docs.charterfnd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.charterfnd.com/technical-documentation/core-agreements.md). # Core Agreements A traditional token launch requires builders to assemble a number of core legal agreements independently, often across multiple jurisdictions and advisors. The Charter Process is implemented through a defined set of legal agreements. By standardizing the core legal documentation layer, while connecting builders directly with counterparties who are already familiar with the framework, Charter simplifies the legal work involved. This helps reduce legal cost, shortens timelines, and ensures that the launch is executed within a cohesive and well-understood legal structure. While the templates provided are a great start, it is essential that Builders retain their own counsel. Firms such as Renno & Co, Cooley, and Fenwick, are already familiar with the Charter framework, and can provide builders with targeted advice without needing to re-explain the underlying structure, reducing legal cost and negotiation time. #### Charter Services Agreement **Parties**: Builder Labs Company ↔ Ink Foundation (Charter’s Facilitating Partner) **Purpose**: Governs the builder’s participation in the Charter framework, the commercial terms of the engagement, fee structure, and token allocation. **Key Terms**: * scope of services, * fee structure (cash + token allocation), * obligations of the Builder during each phase, * role and limitations of the Ink Foundation, * conditions for launch authorization. #### Builder Services Agreement **Parties**: Builder Labs Company ↔ Cayman Launch Company (continuing with the Post-Launch Foundation upon conversion) **Purpose**: Governs the ongoing relationship between the Builder Labs Company and the Cayman Launch Company. This is the agreement that establishes the Builder Labs Company as a service provider to the Cayman Launch Company. This agreement is central to maintaining the structural independence between the Builder Labs Company and the Cayman Launch Company, whilst ensuring that the Builder Labs Company is compensated for its contributions to the network. **What Charter Provides**: Charter provides a standardized template for the Builder Services Agreement, reflecting the structure and mechanics of the Charter process. Because the agreement is designed to survive conversion and govern the relationship over the long term, the template is built to be durable, addressing not only the launch period but the post-launch operating environment. This agreement will require consultation with the legal and tax advisors to the Builder Labs Company. **Key Terms**: * scope of services provided by the Builder Labs Company (software development, protocol maintenance, technical support, and related services), * compensation structure, * performance obligations and service standards, * intellectual property ownership and licensing terms as they relate to the services, * the arm’s-length nature of the relationship and the independence of the Cayman Launch Company, * survival and continuity provisions ensuring the agreement carries forward upon conversion of the Cayman Launch Company into the Post-Launch Foundation. #### Builder Asset Transfer Agreement **Parties**: Builder Labs Company ↔ Cayman Launch Company **Purpose**: Links the builder’s technology, protocol, or intellectual property to the launch structure. The asset transfer agreement governs the licensing of IP (and, where appropriate, assignment) from the Builder Labs Company to the Cayman Launch Company, ensuring that the launch vehicle has the necessary rights to operate the protocol and issue the token. The precise structure of the IP arrangement depends on the nature of the project. Charter generally recommends that the Builder Labs Company retain ownership of core technology and intellectual property and grant the launch structure a broad license to use and commercialize those assets, rather than assigning ownership outright. A licensing approach preserves enterprise value at the Builder Labs level, creates clearer alignment for investors, and protects core technology if an issue arises at the launch structure level. Outright assignment may be appropriate in certain cases, but licensing is the default model under the Charter framework. Either approach gives the Cayman Launch Company the rights it needs to govern and operate the network. **What Charter Provides**: Charter provides a standardized template for the Builder Asset Transfer Agreement, aligned with the Charter structure and the role of the Cayman Launch Company. This agreement will require consultation with the legal and tax advisors to the Builder Labs Company. **Key Terms**: * license or assignment of IP (as appropriate), including the specific rights granted, * ownership of underlying technology, including any improvements or derivatives created during the Charter process, * representations and warranties regarding IP rights, including that the builder has the authority to grant the relevant rights and that the IP does not infringe third-party rights, * limitations on use outside the launch context, * survival provisions ensuring the IP rights carry forward upon conversion of the Cayman Launch Company into the Post-Launch Foundation, * treatment of operational control assets beyond traditional IP, including domains, websites, hosting infrastructure, code repositories (e.g. GitHub), social media accounts, and developer tooling, specifying ownership, management rights, and transition mechanisms, as these assets are increasingly treated by counterparties and regulators as practical indicators of who operates a protocol. #### Token Memorandum **Purpose**: Provides a legal analysis of the Token and the proposed launch structure, providing assurance that the Token launch does not trigger securities law. A Token Memorandum is not required in all cases, but is strongly recommended for most projects, particularly those seeking exchange listings, institutional participation, or operating across multiple jurisdictions. **What Charter Provides**: Charter works closely with offshore counsel such as Carey Olsen, who have been involved in developing the Charter framework and are therefore well positioned to analyze tokens launched through it. Builders are able to engage directly with counsel who are already familiar with the structure, enabling: * faster preparation of legal analysis, * alignment between token design and regulatory considerations, * smoother coordination with exchanges and counterparties. **Key Elements:** * characterization of the Token, * analysis under applicable securities and regulatory frameworks, * description of the issuance structure, * risk factors and disclaimers, * jurisdictional considerations. **EU distribution and MiCA**: Where a project expects meaningful engagement from European users or counterparties, including distribution through venues with an EU presence, reverse solicitation is unlikely to provide a practical basis for broad token distribution. In these cases, a MiCA-aligned whitepaper or enhanced disclosure package should form part of the standard launch process. Token classification is closely linked not only to the token itself but to how, where, and to whom the project is marketed; marketing strategy should therefore be assessed alongside the intended distribution strategy rather than as a separate workstream. Charter works with EU counsel familiar with the framework to prepare MiCA-aligned documentation where a project’s target markets and distribution plans call for it. #### Token Purchase Agreement **Parties**: BVI Launch Subsidiary ↔ Builder Labs Company **Purpose**: Governs the transfer of tokens from the BVI Launch Subsidiary to the Builder Labs Company. This agreement establishes the terms under which the builder receives its allocation of the project’s tokens, including the amount, pricing, vesting schedule, and any conditions or restrictions on transfer. The Token Purchase Agreement ensures that the transfer is documented as an arm’s-length commercial transaction between two distinct entities, consistent with the structural separation that underpins the Charter model. **What Charter Provides**: a standardized template for the Token Purchase Agreement, aligned with the Charter structure and the role of the BVI Launch Subsidiary. Builders may work with their own counsel or engage Charter ecosystem partners such as Carey Olsen or Renno & Co to tailor the agreement to their specific circumstances. **Key Terms**: * number and class of tokens to be transferred, * purchase price or other consideration (if applicable), * vesting schedule and lockup periods, * conditions precedent to transfer (e.g., successful TGE), * transfer restrictions and resale limitations. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.charterfnd.com/technical-documentation/core-agreements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.