The Wisp whitepaper.

Purpose and operating model

Investment communities need a way to change their investment approach without rebuilding custody, accounting and decision-making around a new manager. Wisp separates these responsibilities.

Token holders approve capital allocation. Contributors define strategies and accept published compensation terms. Execution agents submit transactions. Vault contracts enforce permissions. Monitoring services publish valuations and trigger protective actions. A security council holds narrowly defined pause powers.

The protocol follows a repeated operating cycle: proposal, review, vote, funding, execution, settlement and renewal. Each cycle creates a permanent record connecting a strategy to the capital it received, the risks it took, its costs and its results.

Wisp’s first operating scope is deliberately limited to unleveraged, onchain spot strategies on Robinhood Chain. A mandate may hold approved settlement assets or trade approved liquid assets through reviewed adapters. Borrowing, short positions, derivatives, cross-chain bridges, centralized exchange accounts and unrestricted external calls are outside the initial permission set.

An investment mandate is an authorization to manage a specified amount of protocol capital for a specified period. It does not transfer ownership of the capital to the manager. Failure to attract sufficient voting participation or operating capital leaves the treasury idle rather than granting discretionary authority to the founding team.

Network and Pons launch integration

Robinhood Chain provides the execution environment for the token, treasury contracts, strategy vaults and governance transactions. Its mainnet chain ID is 4663 and its native gas asset is ETH. These network properties are documented by Robinhood in its network configuration.

Wisp will launch through Pons. The precise factory version, quote asset, token supply, creator revenue configuration, initial purchase, market contracts and liquidity arrangements must be recorded in a public launch manifest before trading starts. Pons has published different launch architectures; Wisp binds its integration to the contracts actually used for its launch rather than assuming that documentation for another version applies.

The intended launch configuration is a fixed supply of 1,000,000,000 Wisp and a 2% creator fee where supported by the selected Pons deployment. The effective trade cost also includes Pons and venue charges. The launch manifest must state the actual combined charges, any temporary launch protection charges and exemptions. If the selected deployment cannot implement these terms, a revised configuration must be published before launch.

The token follows the selected launchpad’s distribution mechanics. Wisp does not assume that a custom team allocation can be inserted into a factory-issued token. No discretionary post-launch minting is part of this design. The launch manifest must verify mint authority, owner privileges, transfer restrictions, burn support and the complete initial supply movement.

Any founder or treasury purchase uses disclosed funds and appears as a purchase in the ownership record. Tokens held by pools, launch contracts, burn destinations and governance escrow must be identified separately from freely held balances.

Token purchases through Pons fund the launch mechanism and its market according to the applicable contracts. They must not be presented as deposits into Wisp’s investment treasury. Pool liquidity, trading volume, token market capitalization and treasury capital are distinct quantities.

Wisp receives only the creator revenue actually payable to its configured recipient, plus disclosed direct capital contributions. Pons protocol revenue and market liquidity are not Wisp assets. The Pons interface and Pons documentation are external integration references; the launch manifest and verified contracts determine Wisp’s actual configuration.

Treasury funding and capital accounts

The treasury is funded by creator revenue received from the launch market, retained strategy proceeds and explicitly accepted contributions. Wisp does not offer public deposit accounts or issue redeemable treasury shares under this specification.

The creator revenue recipient must be a Wisp Fee Receiver contract where the launch mechanism supports it. If Pons requires a claiming account, the designated collection multisignature forwards receipts to the Fee Receiver and publishes both collection and forwarding transactions. The dashboard distinguishes fees accrued externally from funds actually received.

Every receipt has a source, asset, amount and transaction reference. The initial allocation of received creator revenue is:

The percentages apply to assets actually received after external deductions. Native ETH needed for gas remains in a capped gas account and is charged to the relevant reserve. Wisp-denominated receipts are recorded as token inventory, excluded from investable capital and excluded from treasury NAV. They cannot be treated as cash at the spot token price.

The Investment Treasury and reserves are separate contracts or enforceably separated balances. An execution agent has no spending authority over the reserves. Moving reserve money into the Investment Treasury requires governance approval and is classified as a capital contribution to the investment ledger, not investment income.

The initial reporting and strategy settlement asset is WETH. NAV and capital thresholds are denominated in WETH; supplementary USD estimates are informational and require a timestamped reference price. Introducing a stablecoin settlement asset requires a separate approval covering its contract, liquidity, issuer restrictions and valuation method.

Strategy activation requires at least 5 WETH of unencumbered Investment Treasury assets, a funded operations budget covering three months of approved expenditure, functioning monitoring and a completed security review of the enabled contracts. If the capital threshold is unmet, received funds remain in their designated accounts.

Capital contributions are irrevocable additions to protocol capital under published acceptance terms. They create no repayment promise, additional voting rights or preferential claim. Unexpected token transfers are quarantined from performance accounting until classified.

Token rights and governance participation

Wisp is the protocol’s transferable governance token. Holders use it to authorize investment mandates, operating budgets, supported integrations and prospective changes to economic policy.

Token ownership does not create a contractual right to redeem treasury assets, demand a profit distribution or receive a fixed yield. The protocol’s economic connection to the token is the profit-funded purchase policy defined below. The market price can diverge substantially from treasury value.

Governance operates through a separate Voting Escrow contract so it does not require the launchpad token itself to implement voting checkpoints. Deposits create nontransferable accounting entries, not another transferable token. Voting weight is one vote per eligible Wisp.

Each deposit becomes eligible after seven full days. The escrow checkpoints eligible balances and delegations. Deposits with pending withdrawals have no weight for newly created proposal snapshots. A withdrawal requires a seven-day cooldown and is blocked until all proposals for which the deposit was snapshot-eligible have passed their voting and execution windows. Defeated, canceled or expired proposals release that encumbrance.

Delegation changes apply prospectively through checkpoints. A proposal uses balances and delegation at its fixed historical snapshot. Moving delegation cannot multiply votes or rewrite an existing ballot. The escrow must aggregate eligibility lots so newly deposited tokens cannot inherit the age of an older balance.

Tokens owned by Wisp treasury and reserve contracts cannot vote or delegate. Tokens held by market pools, launch contracts and burn destinations contribute no voting power. Participation does not earn automatic token emissions.

Voting eligibility creates a capital commitment period, but does not eliminate concentration, coordinated wallets or borrowed-token influence. The dashboard therefore publishes the largest delegates, proposal turnout and changes in eligible voting supply.

Governance process

A proposal must contain both a human-readable explanation and the exact executable payload. The proposal identifier commits to the chain ID, target contracts, calldata, document hash and a unique nonce. Changing a material term requires a new proposal.

Abstentions count toward participation quorum but not the approval percentage. Quorum is measured in fixed token units so token burns or low participation do not automatically lower the requirement. Thresholds are initial protocol parameters and changes require a constitutional proposal.

Constitutional proposals include contract migrations, voting rule changes, fee-routing changes, changes to buyback policy, new categories of strategy risk, and replacement of security council members. Ordinary proposals include mandates within existing limits and itemized budgets.

Approved funding proposals reserve capital when queued. Execution rechecks free balances, current risk limits, mandate start deadlines and oracle validity. A proposal that cannot satisfy these checks fails without partial funding. Simultaneous approvals cannot spend the same balance twice.

A mandate must be funded within its execution window and begin no later than 14 days after approval. Unexecuted proposals expire. Governance does not automatically reduce quorum or delegate voting authority to the team when a vote fails.

Anyone may execute a queued proposal after its delay if all checks pass. The proposer may cancel before voting starts. After voting starts, cancellation requires a narrowly defined invalidation condition, such as a changed target code hash, or a governance-authorized cancellation. A security pause can block execution during an incident but cannot rewrite the vote.

Strategy submissions and manager accountability

A strategy proposal must disclose the operator’s addresses, beneficiary address, strategy description, requested WETH allocation, assets, venues, adapter versions, position limits, duration, benchmark, expected transaction frequency, all requested fees and an unwind procedure.

It must also explain its principal failure modes, dependencies, valuation sources, expected liquidity and the evidence supporting the strategy. Historical results must identify their observation period and distinguish live trading, paper trading and backtests. Simulated results never count as treasury returns.

A first-time manager may request at most 2% of Investment Treasury NAV. An established manager may request at most 10% per strategy, with at most 20% aggregate capital across related mandates. Related strategies must be disclosed together for review. Address changes alone do not establish a new independent manager.

The initial mandate duration is 30 days, with an allowable range of 7 to 90 days. Mandates cannot renew automatically. Increasing an allocation, adding an asset or venue, increasing a fee, replacing a beneficiary or widening permissions requires another vote.

Every funded manager posts a bond of 100,000 Wisp before activation. This bond provides an accountability mechanism rather than meaningful insurance against the allocated capital. The bond remains locked until 30 days after final settlement.

Ordinary investment losses, benchmark underperformance and rejected proposals do not forfeit a bond. The initial contracts permit forfeiture only for objectively verifiable signed violations: an operator signing two conflicting settlement attestations for the same mandate and accounting period, or signing a transaction authorization that explicitly directs vault assets to an unauthorized beneficiary. Evidence must include signatures, mandate identifiers and the conflicting payloads.

A 14-day dispute period precedes bond forfeiture, and a constitutional vote resolves contested evidence. The evidence and resolution remain public. Suspected misconduct without verifiable evidence can justify refusing renewal but cannot create arbitrary confiscation authority.

Performance records remain attached to the strategy and manager lineage, including unsuccessful and terminated mandates. Replacing an operator does not erase the strategy’s prior losses.

Mandate lifecycle and contract permissions

A mandate moves through Proposed, Approved, Funded, Active, Exit Only and Settled states. Paused is an overlay that can disable active permissions without changing ownership or deleting the state history. Expired proposals cannot become funded.

The Mandate Registry stores the approved capital ceiling, operator key, beneficiary, adapter hashes, asset addresses, position caps, fee terms, start time, expiry time, exit deadline and settlement policy. The strategy document is content-addressed so readers can verify the version approved by holders.

The Treasury transfers capital only to a vault deployed by the approved Vault Factory. Each vault belongs to a single mandate lineage. The manager receives permission to invoke reviewed adapter functions; it receives no unrestricted withdrawal permission.

Every transaction checks the caller, mandate state, deadline, nonce, adapter and target identifiers, permitted assets, spending amount, output constraints and relevant portfolio limits. Output assets and venue withdrawal proceeds must return to the same vault. Treasury returns use a fixed destination.

Unlimited token approvals, arbitrary delegate calls, arbitrary multicall targets and external asset transfers are prohibited. Adapters must validate recipients inside nested call data, not merely check the outer router address. Approvals are exact or bounded and cleared when no longer required.

Vaults enforce a reentrancy guard and reject nonstandard assets unless their transfer behavior has been reviewed. External venue upgrades or changed target implementations invalidate an adapter until reviewed. Permission checks include dependency code hashes where meaningful, while proxy administration remains a disclosed external dependency.

Mandate expiry immediately disables opening or increasing risk. Exit Only allows a restricted set of conversions to WETH and transfers back to the Investment Treasury. The ordinary unwind deadline is 72 hours after expiry. Positions that cannot be closed remain visible as unsettled exposure; the contract does not fabricate a WETH balance or force a trade without valid price protection.

A manager can be replaced during Exit Only through governance. Protective pauses cannot expand the list of destinations or authorize withdrawals to council members.

Initial capital and execution limits

The following are initial hard ceilings. An individual proposal may choose tighter settings.

The limits are checked before funding and after each adapter operation using valid valuations. Market movements may cause a passive breach without any transaction. A breach blocks transactions that increase the breached exposure and moves the affected mandate to Exit Only where the policy requires.

Wisp itself cannot be an investment asset in a strategy vault. This prevents the treasury from manufacturing performance by buying its own governance token. Buybacks run through a separate budget and are excluded from investment returns.

A loss trigger is a request to stop increasing exposure and begin an orderly exit. It cannot guarantee the final loss percentage. Illiquidity, gaps, chain outages, stale prices and transaction failure can produce losses beyond the trigger.

No initial mandate may borrow, grant collateral rights, bridge assets or deposit into an unreviewed yield contract. A yield integration requires its own reviewed adapter and constitutional approval before any mandate can use it.

Pricing and valuation

Each approved asset requires a valuation policy with the exact source addresses, decimal normalization, maximum age, liquidity checks and fallback behavior. Spot prices from the execution pool alone are insufficient for capital allocation or settlement.

For assets with a suitable independent feed, the Oracle Guard validates price positivity, timestamp and source-specific heartbeat. For assets lacking such a feed, a proposal must demonstrate two sufficiently independent market references with at least 30 minutes of observation and a reviewed liquidity threshold. If reliable independent valuation is unavailable, the asset is ineligible.

An inter-source deviation above 2%, an expired heartbeat, a detected sequencer outage or invalid observations blocks new exposure and profit settlement. Exit transactions also require valid conservative price protection; monitoring may request a pause instead of forcing a sale into a compromised market.

Strategy NAV equals conservatively valued assets plus collectible receivables, less liabilities, accrued expenses and exit costs. Receivables with uncertain collectability are valued at zero until resolved. Locked or restricted positions require explicit discounts and cannot be treated as immediately spendable reserves.

The accounting service publishes daily NAV checkpoints and records every external capital flow. Returns use time-weighted calculations with a valuation at material flows, so a new treasury contribution cannot appear as investment performance. Drawdown uses the same flow-adjusted series.

The UI shows the last valuation time and whether the value is current, stale or under dispute. Estimated USD values never replace WETH-denominated accounting.

Manager fees and strategy settlement

Managers receive no annual management fee under the initial policy. A mandate may approve a performance fee between 0% and 10% of eligible gains. Transaction fees and approved direct expenses reduce results before the performance fee is calculated.

Performance fees crystallize only after full conversion to the settlement asset, reconciliation of liabilities and completion of the settlement challenge period. Partial cash withdrawals cannot trigger a fee while unvalued risk remains.

Each strategy lineage maintains a high-water mark adjusted for capital additions and returns. Reopening a mandate, changing its name or appointing a replacement manager cannot reset an outstanding recovery deficit. Recovering an earlier loss is not a new fee-bearing gain.

For a fully liquidated strategy with no intervening capital flows:

Eligible manager gain = maximum of zero and settlement proceeds after direct expenses minus the applicable adjusted high-water mark.

Manager fee = approved fee rate multiplied by eligible manager gain.

The performance fee cannot be charged twice on the same gain. The settlement record updates the high-water mark and recovery ledger before payment. Where capital changes during a mandate, the accounting engine uses unitized participation with checkpoints at each flow rather than applying the simple formula to a changed principal.

Settlement proposals are posted with transaction references and a reproducible calculation. Three of five disclosed accounting attestators must sign the same record. A 72-hour challenge period follows. A valid conflicting report freezes payment and buyback settlement until reconciled; it does not freeze ordinary return of liquid assets to the treasury.

Accounting attestators can certify records and block settlement through disagreement. They cannot move vault assets, approve strategies or change beneficiaries. This role is a human-supervised trust dependency, and its signatures and any corrections are public.

Investment profits and token purchases

Investment gains and creator revenue use different accounting rules. Creator revenue follows the 80% investment, 15% operations and 5% security routing. Eligible investment profits follow:

Profit allocations are assessed monthly after settlement. They apply only to new, eligible net investment profit after manager fees, direct expenses, accrued investment liabilities and recovery of prior investment losses across the treasury.

Capital contributions and creator revenue are excluded from investment profit. Unrealized gains, self-token inventory and uncollectible income cannot fund purchases. A profitable individual manager does not establish protocol-wide distributable profit while other strategies carry offsetting losses.

The accounting ledger maintains cumulative realized investment profit R, cumulative total investment profit T including conservative unrealized losses and gains, and cumulative profit already assigned to the three destinations A. Creator revenue and contributions are removed from both profit series. Transfers to the purchase contract or Operations Reserve are added back when deriving investment performance so they are not misclassified as trading losses.

New eligible profit is the greater of zero and the smaller of R minus A and T minus A. This amount is further capped by free settled liquidity after liabilities, capital commitments and the required reserve floor. A is incremented by the whole assigned profit, including the retained 60%, so retained earnings cannot be assigned again next month.

An unrealized loss can reduce T and block distribution even when R remains positive. Subsequent recovery must first restore the previous assigned-profit watermark. Prior purchases are not reversed if later losses occur.

The 25% purchase allocation moves to a dedicated Purchase Executor. Its initial daily spending ceiling is the smaller of 0.25% of current Investment Treasury NAV and 5% of independently filtered prior-day Wisp trading volume. Each order must also satisfy a reviewed depth cap and a maximum 1% deviation from an approved reference. Suspected self-trading is excluded from volume estimates.

The executor spreads purchases across at least 24 hours using permissionless bounded execution. It skips orders when liquidity or price protection is insufficient. Unspent budget remains queued and is reported separately from completed purchases.

Purchased Wisp is retired using a verified burn function where supported. Otherwise it is transferred to a disclosed inaccessible destination, reported as retired circulating inventory without claiming that ERC-20 totalSupply decreased. The retirement mechanism is fixed in the launch manifest.

Purchases create market demand only when the protocol has eligible profit and sufficient execution conditions. They do not establish a token price floor, guaranteed appreciation or a redemption mechanism.

Worked treasury cycle

The following example illustrates the accounting policy and is not a forecast.

Assume the protocol receives 10 WETH in creator revenue. It routes 8 WETH to the Investment Treasury, 1.5 WETH to operations and 0.5 WETH to security. These receipts are revenue funding, not strategy returns.

An established manager receives an approved 0.8 WETH allocation, equal to 10% of Investment Treasury NAV. The remaining 7.2 WETH stays unallocated. A first-time manager would instead be limited to 0.16 WETH.

After 30 days, the strategy closes all positions and produces 0.88 WETH after venue charges, gas reimbursements and other approved direct expenses. There is no prior recovery deficit. Its gain before manager compensation is 0.08 WETH.

At a 10% performance fee, the manager receives 0.008 WETH. The treasury receives 0.872 WETH, including its original 0.8 WETH principal. Net investment gain is 0.072 WETH.

If all other strategies are flat, no liabilities are outstanding and the reserve checks pass, that 0.072 WETH is assigned as follows:

The Investment Treasury ends with 8.0432 WETH after these transfers, before subsequent price movements or receipts. The purchase budget is spent only when execution limits permit.

If another strategy has an unresolved 0.10 WETH loss, protocol-wide profit is negative and the 0.072 WETH cannot be assigned under the profit policy. It remains capital supporting recovery. Manager compensation still follows that manager’s previously approved mandate; the dashboard must show both gross strategy compensation and consolidated results.

Agents and automation

Wisp accepts human-operated and AI-assisted execution under the same permissions. An agent may analyze data, generate a proposal and construct candidate transactions, but its output has no authority until the relevant governance and contract conditions are satisfied.

Agent keys are scoped to a mandate and can be rotated through the approved key-management process. Rotation to a precommitted recovery key can occur after a 24-hour public delay; changing the beneficiary or permission set requires governance. A security council can revoke a suspected compromised key immediately but cannot install a new beneficiary.

Keepers monitor mandate expiry, loss triggers, oracle health, unclaimed creator revenue, settlement deadlines and queued purchases. Keeper compensation comes from an approved budget with a per-call and daily cap. The agent cannot reimburse itself for arbitrary expenses.

Automation is permissionless where practical: any caller may invoke an already-authorized, deterministic action. Transactions use nonces, expiry times and idempotent state transitions to prevent duplicate funding or execution.

Model prompts, market data and external documents are untrusted inputs. Agents cannot convert instructions found in those inputs into new contract permissions. Simulation is required before submission, while the vault independently validates every transaction onchain.

Automation can reduce repetitive work, but the security council, accounting attestators, adapters, oracle sources and operators remain identifiable dependencies. Wisp’s autonomy is bounded by these published controls.

Security authority and upgrades

The initial security council is a three-of-five multisignature with publicly listed signer addresses and disclosed affiliations. Its authority is limited to pausing allocations, revoking execution keys, disabling compromised adapters and activating existing exit restrictions.

The council cannot transfer treasury capital to itself, change profit shares, lower voting thresholds, add assets, authorize new venues or remove a governance timelock. Emergency operations emit a reason hash and affected mandate identifiers. A public explanation must follow within 24 hours.

A pause never grants broader trading authority. Reopening exposure requires an ordinary governance vote after the cause is documented. A continuing pause is reviewed publicly every seven days; it does not expire automatically into unrestricted execution.

Existing strategy vaults use immutable code and a fixed treasury return destination. Reviewed adapters are versioned, and changes apply only to new or explicitly renewed mandates. Core governance or treasury changes use a constitutional migration to newly published contracts, with the seven-day execution delay.

Migration is restricted to a successor registered through governance. Existing vaults first unwind to their fixed treasury; assets then move through the approved migration path. Emergency authority cannot substitute an arbitrary recovery address.

Independent security review must cover custody, adapter recipient checks, governance escrow, queue accounting, oracle failures, fee calculations and migration permissions. Material findings must be resolved or explicitly documented before the affected capability is enabled. Review status, scope and deployed code hashes belong in the public contract registry.

Reporting and public application

The Wisp application provides a treasury dashboard, mandate directory, proposal interface, voting interface, strategy detail pages, accounting archive and contract registry.

The dashboard displays Investment Treasury NAV, free WETH, committed capital, active exposure, creator revenue actually received, reserve balances, liabilities, realized results, unrealized results, manager fees and purchases completed. Wisp’s market capitalization appears separately and never substitutes for NAV.

Each mandate page shows approved versus actual allocation, permissions, remaining duration, holdings, trade history, reference benchmark, net return, maximum drawdown, fees and intervention history. Historical mandates remain searchable after closure.

Accounting checkpoints identify the block number, valuation time, source addresses, source freshness, report hash and attestator signatures. The indexer rebuilds events from deployed contracts and handles reorganizations; the UI labels recent transactions as provisional until the configured chain finality policy is satisfied.

Users can connect an EVM wallet, deposit Wisp into voting escrow, delegate votes, review complete executable proposals, vote and request withdrawal when their escrow commitments permit. Viewing capital and performance records requires no token holding.

The frontend publishes last successful refresh times, preserves the last valid record during outages and marks stale data. It must never fill missing values with invented returns, balances or completed transaction states.

Budgeting and continuity

Operations spending requires an itemized monthly budget identifying vendors or beneficiaries, deliverables, maximum amounts and payment periods. Unspent authorization expires at the end of its period. Budget approval creates a spending ceiling rather than an automatic transfer of the whole reserve to a team wallet.

Recurring infrastructure contracts use capped payment streams where practical. Larger one-time security expenses require separate approval. The Security Reserve is a budget for response work, not an insurance guarantee.

If creator revenue falls, the protocol first reduces optional expenditure and new allocations. Investment principal cannot be transferred to operations through an ordinary budget proposal; such a transfer requires constitutional approval and must be reported as a capital withdrawal rather than a trading loss.

If the founding team stops operating, anyone can continue reading public records and executing already-authorized permissionless actions. Holders can approve replacement operators, infrastructure providers, attestators and council members through the same governance process.

If voting participation is insufficient, mandates still expire and approved exit functions remain callable. No individual acquires unlimited authority by default. Where an external position cannot be unwound, it remains a disclosed recovery case.

Wisp’s continuity depends on executable permissions and accessible records. The operating objective is to make managers replaceable while preserving custody, accounting history and governance commitments.

Principal risks and activation requirements

Treasury capital can lose value through market movements, execution failures, malicious assets, compromised dependencies and strategy errors. A separate vault limits permissions and accounting scope but does not eliminate shared oracle, adapter or venue risk.

Governance can be concentrated or captured. Voting escrow and timelocks increase the time needed to acquire influence, but they cannot establish independent beneficial ownership. A sufficiently powerful voting coalition may approve harmful policy changes within the system’s available powers.

WETH-denominated accounting exposes the treasury and reserve budgets to ETH price movements in USD terms. Token liquidity can disappear independently of treasury performance. Creator revenue is activity-dependent and cannot be treated as a predictable funding stream.

Robinhood Chain, bridging routes, sequencer availability, finality, Pons contracts and market infrastructure introduce external dependencies. Wisp cannot guarantee their continued operation. Asset issuer restrictions may also limit transfers or realization.

The legal treatment of a token-governed investment treasury depends on its actual activities, participants and jurisdictions. The operating entity, applicable participation restrictions and enforceable terms must be established before public strategy activation. Stating governance rights alone does not settle that classification.

Before accepting the first funded mandate, Wisp publishes:

1. The token and launch manifest, including actual distribution and effective fees.
2. Verified treasury, escrow, governor, vault, fee receiver and purchase contract addresses.
3. All administrative roles, signer addresses, timelocks and migration powers.
4. Independent review scope, findings and corresponding deployed code hashes.
5. The initial approved asset, oracle, adapter and venue registry.
6. Reproducible accounting rules and an opening balance sheet.
7. Funded capital and reserve evidence satisfying the activation thresholds.
8. A complete first mandate and a successful governance execution record.

These are operating conditions rather than a calendar roadmap. Token trading may begin before strategy activation, but the application must clearly show whether the treasury is collecting revenue, awaiting activation, actively allocating capital or managing an incident.

Protocol commitments

Wisp organizes community capital around permissions that expire, results that remain visible and operators who can be replaced. Token holders decide which strategies receive funding; approved managers act within isolated mandates; realized performance determines whether more capital should follow.

The initial specification commits to fixed token issuance through the selected Pons launch, disclosed creator revenue routing, bounded spot strategies on Robinhood Chain, governance escrow with historical voting records, public treasury accounting and purchases funded only by eligible investment profits.

Its operating standard is a complete and verifiable chain from receipt of capital to approval, execution, settlement and renewal. Every allocation must be traceable to a vote, every agent action to a permission and every claimed gain to an accounting record.