Skip to content
Whitepaperv1.01 September 2026

Zorpha: verifiable active asset management

A protocol for running curated investment vaults where the manager’s decisions are cryptographically committed and publicly reconstructible, so a track record can be audited by anyone rather than asserted by its owner.

Abstract

Public claims about investment performance are not falsifiable. Screenshots crop, threads get deleted, and a manager who publishes only their wins is indistinguishable from one who only has wins. The information a depositor most needs is precisely the information a manager is least motivated to publish.

Zorpha removes the manager’s editorial control over their own record. Vaults are ERC-4626 contracts with fixed mandates. A manager cannot move funds; they can only produce an EIP-712 signature authorising a rebalance within limits the vault enforces independently. Executing that signature emits a receipt containing the requested exposure, both legs of the resulting trade, the vault’s net asset value at execution, a strictly increasing nonce, and a hash binding all of it. The record is append-only, timestamped, and reconstructible from chain data without trusting any Zorpha service.

$ZOR is a fixed-supply token of 1B units with no mint function and no administrative role. It carries checkpointed governance weight, and half of all protocol fee revenue is used to buy it on the open market and burn it. It confers no claim on revenue and is never required to deposit.

1The problem

Delegated asset management requires the depositor to solve two problems at once: whether a manager is skilled, and whether they are honest about being skilled. The second problem is usually harder, and in public crypto markets it is almost entirely unsolved.

The failure is structural rather than moral. A manager publishing their own history controls what enters it. Selective disclosure requires no lying: publishing the winners and staying quiet about the rest produces a record that is completely true and completely misleading. Survivorship does the rest, because managers who performed badly stop publishing entirely, so the visible population is filtered before anyone reads it.

Existing mitigations do not close the gap. Audited returns are retrospective, expensive, and available only to institutions. Copy-trading platforms show real positions but own the database, so the record is only as durable as the company keeping it. On-chain vaults publish balances, which reveals the outcome but not the decision: a NAV series shows that a vault fell 12%, not whether the manager intended the exposure that caused it.

What is missing is a record of intent, committed before its outcome is known, that the author cannot subsequently edit or omit.

2Design principles

Four constraints follow from that goal. Each of them costs something, and the cost is the reason the design is worth stating explicitly.

Custody is separated from discretion

A manager who can move funds can always exit with them, and no amount of recording changes that. In Zorpha the vault holds assets and no privileged address has a function that transfers them out. The manager’s entire capability is producing a signature. The cost is expressiveness: strategies that need arbitrary calldata cannot be run.

Intent is recorded before outcome

The receipt records the exposure the manager asked for, not a reconstruction after the fact. A rebalance that produced a bad fill still records the target that was requested, so execution quality and decision quality remain separable.

The record does not depend on us

Receipts are events emitted by the vault contracts. The indexer and this website are conveniences over them. If both disappear the record is unaffected, and anyone can rebuild it from an archive node. The cost is that receipts must stay small enough to be economical as events.

Failure is closed, not silent

Where a component cannot do its job correctly it reverts rather than proceeding on a guess. A stale oracle stops rebalancing; it does not price the trade at the last known value. The cost is availability: the protocol chooses to be temporarily unusable over being quietly wrong.

3Architecture

Five contract families, each with one responsibility. Nothing in the trust path is proprietary.

Vaults

Every vault is an ERC-4626 share token over a single underlying asset, with a fixed mandate set at deployment. Three types exist: a long/flat vault rotating one tokenised equity against cash, a rotation vault reweighting a basket of equities against a base asset, and a yield vault routing idle stablecoin through a pluggable adapter. Vaults are deployed through a gated factory rather than permissionlessly, which is a deliberate limitation discussed in section 10.

Strategy executor

A verifier holding no funds. It checks that a rebalance signature came from the vault’s authorised signer, that its nonce is unused, that it has not expired, and that the manager is within a per-vault daily rate limit. It then calls the vault. Submission is permissionless: anyone holding a valid signature can land it, so the protocol does not depend on the manager also operating reliable infrastructure.

Oracles

Vaults price assets through a Chainlink-compatible AggregatorV3 interface, with a per-vault staleness bound and absolute price bounds. Where a production feed exists the vault points at it directly. Where none does, a median oracle aggregates reports from an independent updater set and reverts unless a quorum of them is fresh.

Fee routing

Vaults charge a performance fee above a high-water mark and nothing else. Fees accrue to a treasury contract that splits them on a fixed ratio with no discretion: half to operations, half to a buyback contract. Section 7 covers what the buyback does with it.

Reputation registry

An optional layer where a manager commits a hash of off-chain computed statistics over a stated window. Anyone may dispute a commitment within a challenge period by submitting a differing independently computed hash. A dispute is recorded; it is resolved by a governance arbiter rather than by the hash comparison itself, because deciding which of two off-chain computations is correct is not something the chain can determine.

4The receipt scheme

The receipt is the protocol’s core artefact. Everything else exists to make it trustworthy.

When a rebalance executes, the vault emits an event containing the target exposure, the post-trade balance of each leg, net asset value per share at that moment, the nonce, and a commitment hash. For a single-asset vault the commitment is:

commitment = keccak256(
    manager,        // the signing key, not a display name
    vault,          // which vault
    targetBps,      // exposure requested, in basis points
    navPerShare,    // NAV at execution
    assetLeg,       // underlying held after the trade
    cashLeg,        // cash held after the trade
    nonce,          // strictly increasing per vault
    blockTimestamp,
    txHash
)
Every field the receipt reports is inside the hash. Recompute it from the event; if it does not match, the record has been altered.

A basket vault cannot be expressed in that shape, since it has a weight and a balance per constituent. It uses a separate commitment over the full weight array and every token leg, encoded with abi.encode rather than abi.encodePacked so that two adjacent dynamic arrays cannot be re-partitioned into a colliding input.

What the scheme guarantees

Completeness. Nonces are strictly increasing per vault. A missing nonce is a visible gap, so receipts cannot be selectively omitted without the omission itself being evident.

Integrity. Changing any reported field invalidates the commitment. The hash is computed by the vault at execution, not supplied by the manager.

Attribution. The signing key is bound into the hash. Because submission is permissionless, the transaction sender is often not the manager, so the two are recorded separately and never conflated.

What it does not guarantee

It says nothing about whether a decision was good. A manager can produce a flawless, fully verifiable record of consistently losing money. Verifiability removes the ability to misrepresent a track record; it does not manufacture skill, and the protocol makes no attempt to score managers on returns.

5Pricing and failure modes

Net asset value is computed from oracle prices, so oracle behaviour determines whether share pricing is honest. Three guards apply on every read.

A staleness bound rejects any answer older than the vault’s configured window. Absolute bounds reject answers outside a plausible range, which catches a feed returning zero or a corrupted magnitude. A quorum requirement, where a median oracle is used, reverts unless enough independent updaters have reported recently.

All three revert rather than substituting a fallback. The consequence is that an oracle outage makes a vault temporarily unable to rebalance. Redemptions remain available, and an emergency redemption path exists with an explicit haircut for the case where NAV genuinely cannot be established.

Execution is bounded separately. Each rebalance computes a minimum acceptable output from the oracle price and the vault’s slippage cap, and reverts if the venue returns less. A rebalance that would move exposure by less than the vault’s threshold does not trade at all, which removes the incentive to churn a position for fee-generating activity.

A per-manager daily rate limit caps the damage from a compromised signing key. Worst case is roughly one day of misdirected exposure within the vault’s existing bounds, not loss of principal, because the key cannot withdraw.

6The token

Zorpha ($ZOR) is an ERC-20 with a total supply of 1,000,000,000 units, minted once in the constructor.

The contract has no mint function of any kind, no owner, no administrative role, no pause, no blocklist, no transfer fee, and no upgrade path. Beyond standard transfer and approval, the only state-changing entry points are burn, burnFrom, permit and delegate. Supply is therefore monotonically non-increasing.

Governance weight uses ERC-5805 checkpoints on an ERC-6372 timestamp clock rather than block numbers. Robinhood Chain produces blocks roughly every 0.17 seconds and does not guarantee a stable interval, so a voting period denominated in blocks would drift against wall-clock time.

Distribution

Six allocations, summing to the full supply. The same basis points are hardcoded in the deployment script, which refuses to complete unless the distribution consumes exactly the total supply and the deploying key finishes holding nothing.

AllocationShareTokensAt launchCliffTerm
Community & Ecosystem38%380M8%none4 years
DAO Treasury20%200Mnil6 months4 years
Core Contributors17%170Mnil1 year4 years
Protocol-Owned Liquidity13%130M13%noneunlocked
Early Backers8%80Mnil1 year3 years
Insurance Fund4%40Mnilnonelocked

Circulating supply at launch is 21%, being the Season 1 airdrop plus protocol-owned liquidity. Contributors and backers together hold 25%, receive nothing at launch, and unlock nothing for twelve months.

The float is deliberately higher than is fashionable. A small float paired with a large fully-diluted valuation produces a price discovered against very little liquidity, and every subsequent unlock then arrives into a market that cannot absorb it. Deep protocol-owned liquidity and a real launch float are the structural answer to that, and they are priced as insurance rather than as cost.

Ecosystem emissions, the largest single allocation, are released season by season against published criteria and require a governance decision each time. They are a budget with an approver, not an automatic schedule.

7Value accrual

Vault performance fees flow to the treasury, which splits every asset it receives on a fixed ratio: half to operations, half to a buyback contract. The split is not a governance parameter.

The buyback holds fee revenue and, once its balance clears a threshold, may be triggered by anyone. It swaps the full balance for $ZOR on the open market and burns what it receives, reducing total supply.

Two properties matter more than the mechanism. First, the caller supplies the minimum output they will accept, so a predictable market buy of a known balance cannot be forced into an arbitrarily bad fill. Second, both reported quantities are measured as balance deltas across the swap rather than read from the swap venue’s return value, so a malicious or malfunctioning router cannot cause the protocol to report a purchase or a burn that did not occur.

usdcSpent  = balanceBefore(USDC) - balanceAfter(USDC)
zorBurned  = balanceAfter(ZOR)   - balanceBefore(ZOR)

require(zorBurned >= callerMinimumOut)
ZOR.burn(zorBurned)          // reduces totalSupply
Both figures come from measured balances. The contract cannot report a burn larger than the supply reduction it actually caused.

Burning reduces supply. It is not a distribution, it creates no claim on revenue, and it is not a statement about price. If the vaults earn no fees, no buyback occurs, which is the intended behaviour: the mechanism is a function of protocol revenue rather than a subsidy independent of it.

8Governance

Every privileged action in the protocol is queued in a 48-hour timelock owned by a multisig. There is no path that takes effect immediately, so any change is visible on-chain for two days before it can execute.

The token contract itself has no privileged function, so there is nothing to queue against it. Supply, transferability and the absence of a mint are properties of the bytecode, not policy decisions that governance could revisit.

Deployment ends with the deploying key holding no tokens and no roles. The deployment script asserts this and reverts otherwise, so a launch cannot silently complete with authority still resting on the key that performed it.

$ZOR voting weight is real and historically queryable from launch, but no Governor contract is deployed, so there is currently no on-chain venue to submit or execute a proposal. Delegation is still worthwhile, because it establishes weight from the moment it happens, which is what any future Governor would measure against. Stating this plainly matters more than the feature: a token described as governance-enabled without a venue to govern in is a claim worth qualifying.

Unvested contributor and backer tokens carry zero voting weight. The vesting contract never delegates and has no function permitting it to, so nobody votes with tokens they have not yet earned.

9Risk

Depositing into a smart contract exposes principal to total, permanent, unrecoverable loss. Nothing in this design changes that, and the following are the specific ways it can happen.

Contract defects. An internal review found 24 issues in this codebase, two of which would have caused unrecoverable loss of funds. All are fixed and covered by regression tests, and the suite stands at 97 of 97. Scrutiny is not proof. An external audit is a gate before mainnet, and software of this size can hold defects that no review has surfaced. Every finding from that review is written up in the protocol repository.

Oracle failure. Vaults fail closed on stale or out-of-bounds prices, which converts a pricing failure into an availability failure. This is better, not safe: a feed reporting a wrong but plausible price within its bounds would be acted upon.

Manager conduct. A manager can lose money competently and visibly. A compromised signing key can push exposure to a harmful target within the vault’s limits until it is rotated.

Underlying assets. Tokenised equities can fall, be halted, be delisted, or diverge from the price of the asset they reference.

Governance. Privileged roles exist. A timelock and a multisig delay and publicise their use; they do not prevent it.

Liquidity and regulation. There may be no market in which to sell $ZOR or a vault share at any given price. Regulatory treatment of tokens and tokenised securities differs by jurisdiction and can change, including retroactively.

Nothing in this document is investment advice, an offer to sell, or a solicitation to buy. $ZOR pays no yield and confers no claim on revenue, profit or treasury assets. See the risk disclaimer.

10What is not built

Stating the gaps is part of describing the system. Each of these is a real limitation of the protocol as deployed.

No Governor. Voting weight exists; the venue to use it does not. Changes move through a multisig behind the timelock.

Curated, not permissionless, vaults. A gated factory means Zorpha decides which mandates exist. That is a centralisation the protocol accepts in exchange for not producing a long tail of unreviewable strategies, which would undermine the one property the protocol is for. Opening it requires a manager bond and a review period, neither of which is built.

No manager bonding. Managers have reputation at stake but no capital. A slashing design that cannot be gamed by self-dealing is a prerequisite, and it is not designed yet.

Synchronous deposits only. ERC-4626 settles immediately, which excludes strategies that cannot price a redemption on demand. ERC-7540 asynchronous flows would address it.

Reputation statistics are off-chain. The registry stores commitments, not numbers. Verifying a claim means recomputing it from the public receipt history, and disputes are settled by a governance arbiter rather than by the protocol.

No third-party audit. The gating item before mainnet.

Version 1.0, 1 September 2026. This document describes the protocol as implemented at the time of writing and will be revised as the protocol changes. The contracts are the authoritative specification; where this document and the code disagree, the code is correct and this document is a bug.