> For the complete documentation index, see [llms.txt](https://takes.gitbook.io/takes-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://takes.gitbook.io/takes-docs/technical-design/smart-contracts.md).

# Smart contracts

| Component             | Responsibility                                                                                          |
| --------------------- | ------------------------------------------------------------------------------------------------------- |
| Platform registry     | Holds the roles, maintenance switch, fee recipient and current fee quoter every token on a chain reads. |
| Settlement fee quoter | Prices each request's settlement fee from gas and prices the operator publishes.                        |
| Factory               | Creates tokens, checks seed minimums and runs launch steps.                                             |
| Token                 | Tracks balances, fixed basket, request escrow, fees, and claims.                                        |
| Hub                   | Controls account deposits, withdrawals, trading permissions, and equity observations.                   |

New tokens and hubs use beacon proxies. Each pool retains its own address and state; the beacon selects shared implementation code. On Arc, Ethereum, Base, Arbitrum, and Monad, each token pairs once with a separate HyperEVM hub through CCTP. On HyperEVM, the token creates a dedicated hub connected through local contract calls.

Each chain has one non-upgradeable platform registry. Tokens and hubs read every role and setting from it, so the registry owner can replace the fee quoter or register a new factory without changing existing tokens. Factories are non-upgradeable and hold only creation rules. Separate beacon owners can upgrade every token or hub attached to their beacon. Production beacon ownership belongs to an explicitly configured multisig-controlled timelock with at least 72 hours between scheduling and executing an upgrade. This authority can change custody logic; it is separate from request operator and launcher permissions.

## Strategy identity

New token implementations and factories expose `weightModel() = 2` for notional weights. The factory checks that its implementation agrees and emits `TokenWeightModel` after creation. The leg tuple retains per-asset leverage. The factory seed floor uses the same conservative fixed-point normalization as the off-chain strategy module.

Readers require the notional getter and matching token/factory models. Missing getters, unsupported models, and RPC failures prevent launch or operation.

## Composability

Composability means another application can use a token through its public contract interfaces. Every Takes token is an ERC-20 token, the common interface for balances, transfers, and spending allowances. A wallet or contract can hold and transfer it without using the Takes website.

Every accepted action receives its own `requestId`; track `requests(id)` and request events through acceptance, execution, settlement and delivery. Several requests can be accepted from the same controller; execution is serialized per pool.

Every chain uses the standard `requestDeposit(assets, controller, owner)` and `requestRedeem(shares, controller, owner)`. Overloads with a fourth `maxSettlementFeeAssets` argument revert when the fee exceeds that limit. The registry's fee quoter computes each request's settlement fee onchain from prices the platform operator publishes every 2 minutes, and refuses new requests while those prices are more than 6 minutes old.

All current tokens expose controller-authorized `claim(id, receiver)`, which delivers a settled request to a chosen receiver. `cancelMint(id, receiver)` refunds an accepted buy before execution starts. Claims deliver the whole request entitlement; there are no partial claims or shared controller payout pools. HyperEVM also permits approved operators through `setOperator(operator, approved)`. Deposits require owner or operator authorization; redemptions can also use the owner's share allowance. Controller authority governs cancellation and manual claim receivers.

HyperEVM exposes `asset()`, `share()`, `totalAssets()`, `convertToShares()` and `convertToAssets()`. These views do not make the current interface a complete ERC-7540, ERC-4626 or ERC-7575 implementation. It has no standard pending/claimable request views, synchronous deposit/withdraw methods or partial-claim methods. Conversion views are estimates, not executable payout guarantees.

The current worker serves fresh pools assigned to its operator. Previous deployments and historical batch interfaces are outside this rollout; the app does not load archived pools or automatically migrate their funds. See [Request status](/takes-docs/reference/status-reference.md#request-status).

Public interfaces do not guarantee a lending-market listing, liquidity, or collateral suitability. Each integration must handle fees, delayed settlement, and changing token value.

## Enforced boundaries

The contracts allow only one executing request per token. They check escrow backing, settlement amounts, and matching request identity. Pairing cannot be changed after it is set.

Creation through the app has stronger market and leverage checks than direct contract creation. A token created directly through a factory may not meet all app rules.

Registry maintenance stops new pool creation, request admissions, request execution, and API wallet changes from the factory. Each hub also has a maintenance switch for new Core deposits and withdrawals. Existing confirmations, claims, and recovery remain available. Maintenance is not a trading freeze or a general rescue function. There is no timeout-based refund guarantee. See the [beacon upgrade procedure](https://github.com/ternakkode/takestrade/tree/main/docs/beacon-upgrades.md).

See [Accounting model](/takes-docs/technical-design/accounting-model.md#accounting-model), [Permissions](/takes-docs/security-and-trust/roles-and-permissions.md#roles-and-permissions), and [Contract addresses](/takes-docs/reference/contract-addresses.md#contract-addresses).


---

# 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://takes.gitbook.io/takes-docs/technical-design/smart-contracts.md?ask=<question>&goal=<user_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.