> For the complete documentation index, see [llms.txt](https://docs.motion.tips/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.motion.tips/technical/delegation.md).
# Treasury & Delegation
The $MOTION treasury is a smart-account multisig on Robinhood Chain, and it holds the supply that burns draw from. A burn is a one-way transfer to the dead address, where the tokens sit forever.
Two different powers run this treasury, and it is worth keeping them straight.
* **The backend can burn and pay claims, and can do nothing else.** Our servers hold operator keys. The owners signed scoped permissions for them, and audited smart contracts re-check every rule on every single use, so the limits do not depend on our code behaving.
* **Everything else is an owner action.** Moving treasury funds any other way takes the owners themselves, signing from their own wallets, and it takes more than one of them. No server can do it, and no single person can either.
This page shows you where to check both of those yourself.
## What the burn key can do
The burn authority is one permission. It lets a single backend key do one thing: send $MOTION to the dead address. Here is the full list of what that key can and cannot do, enforced on-chain on every burn:
* **Only one token.** It can touch the $MOTION token and no other contract.
* **Only one action.** It can call `transfer` and nothing else. The token has no burn function, so a burn is just a transfer to the dead address.
* **Only one destination.** The recipient is pinned to the dead address. The key cannot redirect a single token to a wallet.
* **Only so much.** At most 10,000,000 MOTION can move per 30-minute period.
* **No ETH, ever.** The permission moves zero ETH value.
Only a treasury owner can create this permission in the first place, and the `DelegationManager` contract, not our code, re-checks every rule on each burn. In practice the protocol burns far less than the ceiling: the application caps each cycle at 1,000,000 MOTION, and never more than the treasury's own balance.
{% hint style="info" %}
**Under the hood** (for the technically curious)
The treasury signs one root delegation to the burn-operator key. The deployed grant carries exactly three on-chain caveats, checked by the `DelegationManager` on every redemption: an `erc20PeriodTransfer` caveat caps outflow at 10,000,000 MOTION per 1,800-second (30-minute) period; a `valueLte` caveat pins the ETH value to `0`; and an `allowedCalldata` caveat pins the transfer recipient to the dead address. A burn is a `transfer(address,uint256)` because the production token exposes no `burn()`. Separately, the application clamps each cycle's burn to the minimum of its formula amount, 1,000,000 MOTION, and the live treasury balance, so it never approaches the on-chain ceiling.
{% endhint %}
## Who holds the keys?
The application holds no owner key and no admin key. It holds operator keys, and the permissions above scope each one to its single job.
The owners are ordinary wallets, and everything that is not an automated burn or claim payout belongs to them: creating a treasury permission, topping up the treasury, and any other movement of treasury funds. Because they are the treasury's signers, together they can also change the treasury itself, including who the signers are and how many signatures it takes. That is what a multisig treasury is, and it is the same trust any multisig-held treasury asks for. None of it is unilateral and none of it is quiet: the treasury contract decides how many owner signatures an action takes, it is the contract that is asked and not our app, and every owner action lands on-chain in public like any other transaction. Ownership is also the admission ticket: to create a treasury permission, the connected wallet must already be an on-chain owner of the treasury.
{% hint style="info" %}
**Under the hood** (for the technically curious)
Owners are EOAs, and the M-of-N threshold is the treasury's own on-chain `getThreshold()`. Call it on the treasury and read the number back for yourself. At the time of writing it returns `2`, against the `3` owners `getSigners()` lists, so the live configuration is a 2-of-3 and no single owner can move treasury funds or change the treasury's rules. The implementation is the MetaMask Delegation Framework's `MultiSigDeleGator`, so owner actions at threshold include `updateThreshold`, changing the signer set, and upgrading the implementation. Creating a delegation requires the caller's wallet to be an on-chain `isSigner` of the deployed treasury. Owners sign the delegation as EIP-712 typed data inside their own wallets; the app never holds an owner key, and nothing the client sends can widen a permission. The web app and the burn worker read the treasury, operator, and token from the same deployed environment, so they can never disagree.
{% endhint %}
## What can move a burn, and what cannot
Two more things are worth stating plainly, because they are the questions people actually ask.
**Where the numbers come from.** The protocol's indexing engine reads public X activity: the posts, who engaged them, and the public counts attached. Those records are the raw input, and a cycle scores what was observed. Every point, every creator's share, and the burn amount itself are computed deterministically from those records (the same records always produce the same numbers), and the raw records are retained as they arrived, so any cycle is auditable after the fact.
The input is boxed in by two hard ceilings that are not computed from it: the protocol clamps every cycle to 1,000,000 MOTION, and the on-chain permission refuses more than 10,000,000 MOTION per 30-minute period on top of that. Inside those ceilings, the observed activity shapes how big a cycle is and who gets credited. What it can never do, at any size, is move a token anywhere except the dead address, because that is pinned in the contract, not in our code.
**A crash cannot double-burn a cycle.** A burn is signed and written down before it is ever sent to the chain. If the worker crashes mid-burn and restarts, it finds the transaction it already signed and re-sends the exact same bytes. The network recognises them as the transaction it already has, not a new one, so the burn lands once.
{% hint style="danger" %}
A broadcast burn is irreversible. No key exists for `0x…dEaD`, so tokens sent there can never move again.
{% endhint %}
## Check the chain facts yourself
Everything the treasury does is public and on-chain. Production burns run on **Robinhood Chain, chain ID `4663`**, and you can look all of this up on the block explorer, [robinhoodchain.blockscout.com](https://robinhoodchain.blockscout.com).
| What | Address |
| ------------------------------------- | -------------------------------------------- |
| $MOTION token | `0xB0Fea401F1ee62F0e7cC3Bdf94b20c25aB5117e2` |
| Treasury (the smart-account multisig) | `0x33fA782dB72FB755ae64f71c3d326C93e027B366` |
| DelegationManager (checks every burn) | `0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3` |
| Burn operator (broadcasts the burn) | `0x4CF214703d329B681Ebc602bFAA1A96e340b4Ca3` |
| Dead address (where burns go) | `0x000000000000000000000000000000000000dEaD` |
Every burn is a public transaction from the treasury to the dead address. Open the [burn log](https://motion.tips/burn-log), pick any completed row, and its PROOF link opens that transaction on the explorer. Two things to confirm there: the transfer moved exactly the amount the row shows, and it moved from the treasury to the dead address and nowhere else.
Total supply is fixed at 1,000,000,000 MOTION and never changes. A burn moves tokens to the dead address rather than reducing total supply, so circulating supply is total supply minus the dead-address balance. The treasury's own balance is the pool the burns draw from, and it falls with every cycle: call `balanceOf` on the treasury and on `0x…dEaD` and you can price the whole thing yourself, live, any time.
{% hint style="info" %}
**Under the hood** (for the technically curious)
The treasury is a proxy whose implementation is the framework's `MultiSigDeleGator` at `0x56a9EdB16a0105eb5a4C54f4C062e2868844f3A7`. The live bytecode for all three core contracts is pinned by keccak256 hash, so you can confirm the deployed code matches the committed environment:
* $MOTION token: `0x287afd61627652e33bc7e360a04a59e5c0d34a50914266397bb358583a53b598`
* Treasury: `0x8678a7d794f76a790255c0db52d6276dc7259cc7a211426bca106e5ebb4b1ddf`
* DelegationManager: `0xe45747f90ecec2ba96ae9f4a15c36289653efdfef7690bcfb90a1945bb0fe207`
Startup validation checks `eth_chainId` and bytecode-verifies the token, treasury, and `DelegationManager` on the live chain before any burn is trusted. Each burn also publishes an evidence hash, the SHA-256 of that cycle's inputs, so a past burn can never be quietly re-scored under new rules.
{% endhint %}
## How the burn authority is contained
Containment works at two layers, independent by design.
**The application layer can starve it.** An admin flips `markRevoked` in the application's delegation store, and every burn cycle that starts after the flip finds no delegation and does nothing. Revocation works at the granularity of a cycle: a cycle already past its lookup, or a transaction already signed and on the wire, runs to completion, deliberately, because signed bytes abandoned on the network are how a burn lands twice. Recovery finishes what exists and signs nothing further.
**The chain scopes it.** The permission itself is the wall: even a fully stolen operator key can only ever send treasury tokens to the dead address, at the capped per-period rate, destruction on a leash, never theft. It cannot reach a wallet, another token, or a single wei of ETH. And rotating an operator key is an owner ceremony, signed from an owner-controlled wallet, never a server.
## What is the Smart Accounts Kit?
It is MetaMask's smart-accounts SDK plus its on-chain **Delegation Framework**: smart-contract accounts, a `DelegationManager` contract, and a library of small rule-checking contracts called caveat enforcers ([MetaMask's docs](https://docs.metamask.io/smart-accounts-kit/)). MetaMask pitches it as programmable account behavior with rule-based permission sharing, and that is exactly the part Motion runs on.
A **delegation** is a signed message. In it, one account (the **delegator**) grants another account (the **delegate**) permission to perform specific actions under strict conditions. The chain re-checks those conditions every time the permission is used. For $MOTION, the treasury is the delegator, the operator keys are the delegates, and the conditions are the rules listed above.
{% hint style="info" %}
**Naming note.** MetaMask formerly shipped this as the "Delegation Toolkit". Same SDK, same framework (npm: `@metamask/smart-accounts-kit`); only the name changed, and older Motion material may still use the old one.
{% endhint %}
## Why $MOTION builds on it
$MOTION burns on a fixed cadence: one burn every 30-minute cycle, up to 48 treasury transactions a day. That cadence is the whole design problem, and the two obvious ways to run a treasury both fail at it.
* **A plain multisig.** Its owners would have to hold a live signing ceremony for every single burn. That is 48 ceremonies a day, every day. The moment a signer is away, burns stall.
* **A backend admin key.** It keeps up with the cadence, but a key that can move treasury funds can move them anywhere. One server compromise drains the treasury.
The Smart Accounts Kit gives you the speed of an admin key with the safety of a multisig. The owners sign once. From then on the contracts carry every burn and enforce the rules, instead of trusting anyone to follow them.
Tipping runs on the same building block, one level up. A tip itself never touches the chain: it moves allocation between accounts in the protocol's ledger, person to person, until someone claims. What the owners signed is a second scoped permission, separate from the burn's and held by its own key, that lets the backend pay a creator's accumulated claim out of the treasury, inside its own hard caps. One signed grant covers every claim; no per-tip permission exists, and no tip waits on a signing ceremony. The plain version is on [Tipping](/tip-on-the-timeline.md).
## Built on audited, open-source contracts
$MOTION does not roll its own treasury contracts. It builds on MetaMask's Delegation Framework, which is open source, independently audited, and public. You can read the code and the audit reports in the [framework repo](https://github.com/MetaMask/delegation-framework), and $MOTION pins the on-chain framework to release tag **v1.3.0**.
{% hint style="info" %}
**Under the hood** (for the technically curious)
$MOTION pins exact versions so an upstream change lands in one place: `@metamask/smart-accounts-kit` at `1.6.0` (exact, no caret), `viem` at `2.55.2`, and the on-chain Delegation Framework at release tag `v1.3.0`. The standards involved: **EIP-712** is how owners sign the delegation as typed data from their own wallets; **ERC-7710** defines `redeemDelegations`, the interface the operator calls each cycle; **ERC-7579** defines the execution modes.
{% endhint %}
---
# 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.motion.tips/technical/delegation.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.