The FundController owner initially manages display metadata, team fees, swap fee recipients, signal settings, strategies and the destination of future mining revenue. Each component can be transferred to an independent owner through an immediate one-step handoff. These powers matter to holders as well as teams.

Managing a fund

Manage is shown to the connected fund manager, controller owner, authorized component owners and an ownership nominee. A compact toast appears on each visit and dismisses automatically; hover or focus it to keep it open. Don’t show again remembers the preference for that wallet in this browser. This is a management interface, not private storage: fund data and transactions remain public onchain, and each contract still checks permission before changing settings.

Manage has three sections:

• Revenue starts with recorded revenue in USD and a compact cumulative chart. The chart and headline sum the same team credits, using verified recording dates and historical prices. Hover or use the arrow keys to inspect a date. One Available fees card groups Mining and Swaps with Collect all fees and secondary controls for each source. Collection history is shown first; Details reveals recipients and accounting information. Available fees shows a combined USD estimate at current prices, with separate token balances for Mining and Swaps. It includes uncollected swap estimates; an unknown nonzero token value makes the USD sum unavailable without blocking collection. Collect all fees runs the required mining and swap transactions; wallets that support batching confirm them once, and other wallets may ask for more than one confirmation.
• Assets shows the fund's assets, values and weights. Add assets opens the strategy editor; less frequent controls are under Signal settings.
• Settings contains fund details, Fees & recipients, Signal settings and Access. Signal settings groups the signal managers (with a list of current managers and any positions left by removed managers), the permanent switch to holder-led, and signal reward controls. Access contains ownership transfers and renouncing ownership. Mining and swap fees have separate recipient settings; swaps can route the two tokens to different wallets. A new mining recipient applies to future mining fees, and existing mining balances stay with their recipient. A new swap recipient also receives swap fees earned earlier but not yet claimed.

Revenue history comes from onchain events. The USD total estimates the value of each team credit at the end of its historical block using verified oracle prices and, for fund-token fees, the historical pool spot price. It is historical fee value, not cash received or proceeds from selling fee tokens. It never revalues old earnings at today’s price or counts a collection as new earnings. Mining credits are recorded on takeovers; swap credits are recorded when fees leave the pool, so pending swap estimates stay in Available fees. A complete USD total is withheld if history or historical pricing is missing. Explicit mock deployments use simulated dollar values, and design previews use sample historical prices. Incomplete history is labeled, and a failed balance read is shown as unavailable rather than zero. Mining payments can include miner repayments as well as team fees; the revenue details distinguish these when the event history is complete.

Metadata

The Coin's name and symbol are immutable. New Coin contracts expose their metadata through the ERC-1046 tokenURI() getter. The URI is stored on Coin, is bounded to 2,048 raw bytes and can be replaced by its current owner with Coin.setTokenURI(newURI). FundController initially owns Coin and forwards this update:

FundController.setMetadataURI(newURI);

Passing an empty URI restores a minimal ERC-1046 document containing {"interop":{"erc1046":true}}.

The interface normally encodes this JSON directly into a data:application/json;base64,... URI. It also accepts an IPFS JSON document through the advanced metadata option. An image URI belongs inside the document, not in place of it:

{
  "interop": { "erc1046": true },
  "name": "Example fund",
  "symbol": "EXAMPLE",
  "description": "Creator-supplied description.",
  "defaultMiningMessage": "We Glaze The World",
  "image": "ipfs://bafy...",
  "website": "https://example.com",
  "social": "https://x.com/example",
  "discord": "https://discord.gg/example",
  "telegram": "https://t.me/example"
}

Every link is optional and must use https://. social holds the fund's X profile (x.com or twitter.com), discord a discord.gg or discord.com/invite link and telegram a t.me link. Fund pages list them under a Links menu in the header.

ERC-1046 documents include interop.erc1046: true. Any name, symbol or decimals must match the token's onchain values; descriptions use plain text without markup or newlines. The builder includes the marker automatically. Teams using custom IPFS documents are responsible for these requirements. Existing deployed tokens retain their original interfaces.

Contracts never fetch, parse, validate or freeze metadata. Every update emits TokenURISet(previousURI, newURI) from Coin. The controller’s metadataURI() getter reads the same Coin value. Interfaces label the content as team-controlled and untrusted, fetch it through a constrained proxy with size limits, escape text and reject active content. A metadata change cannot affect mining, fees, auctions, signals, claims or withdrawals.

An optional defaultMiningMessage supplies the interface fallback when a miner leaves their message blank. It is limited to 280 UTF-8 bytes. The chosen message is submitted with the takeover and stored onchain by the Mine; miners can enter their own message instead.

The team fee

The team fee accrues from each mining payment as a pull claim. It defaults to 0.5% of the payment. The FundController owner sets this Coin’s team rate independently from 0.01% to 2%. The Launchpad owner controls the separate protocol rate within the same bounds. Both default to 0.5%; changes affect future payments only. The FundController owner chooses the team recipient, which is set at launch and can be changed later:

FundController.setCreatorFeeRecipient(newRecipient); // zero disables the claim
FundController.setCreatorFeeBps(newBps); // 1 to 200

Changes affect only future accruals. Amounts already recorded for the previous recipient remain theirs to claim through Mine.claimPayment(account), which anyone may trigger. While the recipient is zero, its fee share stays in the remainder sent to the Mine's current revenue destination.

Future revenue destination

FundController.setRevenueRouter(newDestination) changes where future mining remainders are sent. The destination must be a deployed contract, but the Mine does not verify its routing behavior. This can divert future purchases or strand revenue. It does not move old balances or positions, and the controller remains bound to the original Resonance. See Authority after launch.

Ownership

The FundController is Ownable2Step:

FundController.transferOwnership(newOwner); // proposes
FundController.acceptOwnership();            // the new owner accepts
FundController.renounceOwnership();          // permanent

Until the new owner accepts, the current owner remains in control and may replace or cancel the nomination.

Coin, Mine, Resonance and the LP token use one-step Ownable. The controller owner can separately call transferCoinOwnership(newOwner), transferMineOwnership(newOwner) or transferResonanceOwnership(newOwner), and transferLiquidityPoolOwnership(pool, newOwner) for the launch's LP token, whose owner sets its swap fee recipients. Each transfer takes effect immediately and requires a nonzero recipient. The new owner administers the component's settings directly; the original controller can no longer update them. Coin's new owner can change metadata but cannot mint or replace Mine's locked mint authority.

To return a component, its owner calls transferOwnership(originalFundController) directly on that component. No acceptance transaction is needed.

Renouncing FundController ownership disables that controller's actions. It does not revoke independently owned components. Settings on components still owned by the controller become frozen. In that case, managed Resonance also keeps its current signal managers. Existing user exits remain callable under their contract rules.

After a component leaves FundController, its independent owner uses the same settings editor; the transaction is sent directly to that component. Controller ownership actions affect only FundController and remain two-step. If a component's ownership cannot be read, its settings are unavailable until the read recovers.