> For the complete documentation index, see [llms.txt](https://sply-1.gitbook.io/sply/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sply-1.gitbook.io/sply/developer-template-guide.md).

# Developer Template Guide

## Developer Template Guide

This page explains how developers can bring new token behavior into Daoi and turn their mechanism into a public platform template.

### What a developer template is

A developer template is not an isolated token launcher living outside the platform. It is a reviewed extension that becomes part of the public template set and still follows platform launch rules.

### What a template includes

A template usually includes:

* a deployer
* a token core or token core deployment path

The deployer is responsible for decoding parameters, producing the token core, and exposing the hooks that the platform expects.

### Submission path

Developers submit:

* deployer information
* template name and description
* parameter structure
* review notes and supporting materials

Submission enters a review queue first. It does not become public immediately.

### Review and registration

When a template is approved, the admin side registers it through `FactoryAdmin`. Once registered:

* it receives a template id
* it becomes available in the public template list
* project owners can select it from the create page

### Required token-side hooks

Custom token cores must fit the platform lifecycle. That means they must support the hooks the platform relies on during launch and finalize, including:

* `setPresale`
* `setTaxStrategy`
* `setMarketConfig`
* `enableTrading`
* `lockAfterFinalize`
* `renounceByPresale`
* `clearPresale`

### Why the platform imposes those constraints

Because Daoi does not let templates take over fundraising and settlement responsibilities. Templates can extend token behavior, but they still need to cooperate with:

* platform custody
* presale state
* finalize state closure
* source verification

### Platform custom core support

The current architecture also supports developer templates entering the platform-managed `CREATE2` path, which means developer templates can use the same address-planning and verification model as official platform paths when they satisfy the required interfaces.

### Design recommendations

* keep the deployer focused on deployment and initialization
* keep custody logic out of custom token code
* avoid hidden mint, blacklist, or finalize-bypass logic
* define template parameters explicitly through `abi.decode`
* design the token core to be verifiable and reviewable

***

## Agent Instructions: 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:

```
GET https://sply.fun/daoi-docs-import/developer-template-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language. 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.


---

# 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://sply-1.gitbook.io/sply/developer-template-guide.md?ask=<question>&goal=<endgoal>
```

`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.
