How strategies execute, where royalties go, and who can change what.
A token’s configured tax proceeds reach its vault. Platform, creator, buyback, and strategy allocations follow the deployment’s published configuration. Exact rates are shown only when available from that configuration.
A hook returns a plan; the vault validates and executes supported actions. A hook cannot directly spend the vault’s assets.
Each published version records its source, code hash, author coin, parameters, and declared lineage. Every adopting coin keeps independent configuration and state.
Eligible strategy expenditure creates a royalty obligation to the root version’s original author coin vault. Derived versions keep their declared authorship, while the root royalty recipient remains unchanged. The term begins when an adopting vault first activates that root lineage; switching versions, forking, or readopting does not restart it. This implementation settles eligible spending and royalties in BNB. The rate and duration are explicit configuration. The payment does not automatically buy the author’s token.
Failed actions, refunds, internal accounting transfers, runtime fees, and royalties themselves are excluded from the royalty base. A version’s lineage is declared provenance; code copied outside this system cannot be forced to pay royalties by this registry.
The project dev can manage configured operators, pause execution, cancel pending changes, roll back eligible versions, and upgrade the vault system through the configured upgrade authority. These powers can affect future strategy behavior.
Asset rescue is restricted to unencumbered project assets. Holder claims, creator claims, voting deposits, and other established liabilities remain reserved; rescue cannot erase those debts. Actual roles and rescue limits must match the deployed contracts.
The coin creator may propose an adopted version for their own coin vault. Configured keepers, the dev, and the protocol Guardian also have their factory-defined proposal permissions. Holding tokens alone does not grant adoption authority. Activation follows the configured public delay. The dev’s emergency controls are separate from community selection.
The vault checks approved action types, assets, recipients, spending budgets, reserves, and transaction constraints. Values are configuration, not promises of investment performance.
AI output and simulations can miss failures. Market prices, external protocols, keeper availability, and upgrade authority introduce additional dependencies. Source and test evidence must be inspected for the exact deployed version.
Live records come from the connected index API. Each response shows its origin and observation time. An empty index, an unavailable service, and an unknown chain value are distinct states. The interactive demo uses clearly labelled fictional data.
This interface prepares drafts and reads public state. A wallet transaction requires exact chain, account, target, calldata, value, and contract permissions to be checked against the project manifest.
Review the exact request above. Each step is simulated before your wallet opens. A receipt, matching event, and state readback are required for confirmation.
No transaction has been sent.