> For the complete documentation index, see [llms.txt](https://synthesys-2.gitbook.io/synthesys-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://synthesys-2.gitbook.io/synthesys-docs/mint-overview/compliance-and-security/token-controls.md).

# Token Controls

Fund tokens issued on the Synthesys platform are **permissioned** by design. Transfer restrictions, access controls, and compliance enforcement are embedded at the smart contract level — not applied as a policy overlay.

***

### How Fund Tokens Differ from Standard Tokens

| Standard Tokens                   | Fund Tokens (Synthesys)                                   |
| --------------------------------- | --------------------------------------------------------- |
| Any wallet can receive tokens     | Only whitelisted, KYC-verified wallets can receive tokens |
| No on-chain identity verification | Whitelist enforced at the smart contract layer            |
| Transfers are unrestricted        | Transfers to non-whitelisted addresses are blocked        |
| No sanctions controls             | Blacklist contracts available for sanctions compliance    |

***

### Fund Token Contract

Each fund on the Mint platform has a unique **Fund Token Contract** — an ERC-compliant smart contract deployed by Synthesys. This contract governs:

* **Token issuance:** Only the Chainlink DTA smart contract can mint new tokens. No other party has minting authority.
* **Token burning:** Only the Chainlink DTA smart contract can burn tokens during redemption.
* **Transfer restrictions:** Token transfers are only permitted between wallets on the on-chain whitelist.
* **Investor whitelist:** Maintained by the Transfer Agent via the Mint UI. All additions and removals are recorded on-chain.

***

### Role-Based Access Control

The minter/burner roles on the Fund Token Contract are granted exclusively to the Chainlink DTA. This means:

* No single operator or administrator can unilaterally mint or burn tokens.
* All subscription and redemption operations go through the Maker/Checker approval model with Safe Multisig execution.
* Contract addresses, roles, and configurations are set at fund initialisation and are immutably recorded on-chain.

***

### Cross-Chain Compliance

For funds using Chainlink CCIP for cross-chain distribution, KYC and whitelist status checks are enforced on the destination chain. Non-compliant wallets cannot receive tokens across chains. All cross-chain transfers are traceable with on-chain transaction hashes on both source and destination chains.

***

### Zodiac zTokens

zTokens minted through Zodiac's Wrap/Unwrap feature are **permissionless** ERC-20 tokens. They can be freely traded, used as collateral, or deployed in DeFi protocols. The permissioned controls remain on the **underlying** fund tokens, which are held in escrow by the Zodiac wrapper contract.

Only whitelisted institutional investors can wrap and unwrap. Retail investors interact with zTokens only and never hold the underlying permissioned tokens.

***

### Audit Trail

Every token operation — minting, burning, whitelisting, blacklisting, and transfers — is logged with:

* User identity
* Action type and timestamp
* On-chain transaction hash

This creates a complete, tamper-proof record from order intake through to final settlement.


---

# 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://synthesys-2.gitbook.io/synthesys-docs/mint-overview/compliance-and-security/token-controls.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.