A simpler customer experience

Status: canonical product rule. This specification controls how the account, provider, chain, automation, and reconciliation architecture is exposed to customers.

The accepted unified thesis and Clubs and Harvest extension add social plan discovery, separately enrolled managed allocations and proceeds routing. These preserve the simplicity and disclosure rules below and do not imply launch approval.

1. Product promise

Forage's primary takeaway is Earn money. Build and trade your own asset bundles. Customers see funded rewards, eligible income and their investment results, then create, hold and trade bundles in their own subaccounts. The earning and asset-bundle specification controls this priority and the bundle lifecycle. Merchant discovery and games support earning and acquisition. The rewards and income architecture controls funding and settlement.

The default navigation is Home, Explore, Portfolio. Home leads with earned cash rewards, received income, realized/unrealized investment results, fees and clearly separate pending amounts. Explore contains earning opportunities, offers and trails. Portfolio prominently shows My bundles, actual holdings and Create bundle, Add, Sell and Rebalance actions. Activity, automation and security are contextual screens. Securities listings and order review occupy their own provider-approved surface, without merchant advertisements or mixed crypto listings.

Public offer discovery can start before wallet creation or brokerage onboarding. Ask for identity, tax and provider information at the point the selected financial product requires it. Opening an income account is optional; earning merchant rewards does not require buying a security.

Forage should feel like one coherent financial application, not a control panel for wallets, chains, bridges, providers, smart accounts, session keys, mirrors, or settlement infrastructure.

Clubs and reviewed shared plans live inside Explore; managed allocations appear in Portfolio with a clear Managed label and operator. A Club is not a fourth required app or an account owner. Join community, Make it mine and Authorize trading are distinct intents. A managed enrollment review must disclose that approved trades within the mandate may happen without per-trade confirmation. Show fees, operator authority, loss risk and any exact reserved coverage before signing. A stop/revoke flow is distinct from selling and withdrawing. Harvest shows source, destination, available amount and costs without calling transfers new earnings. No creator promotion appears inside the financial authorization review.

The guided ownership experience is:

Sign in
  -> confirm eligibility
  -> add funds
  -> create or select a bundle of eligible assets
  -> review the complete economic and legal result
  -> confirm
  -> track progress through final settlement

Forage performs account resolution, provider routing, Account Instance selection, gas preparation, transaction construction, status normalization, and reconciliation behind this flow. The customer should not have to understand the implementation to use the product safely.

The merchant entry path is: discover an offer, inspect the exact benefit and conditions, complete eligible activity, follow Pending to Available, then choose an allowed redemption or financial destination. A destination preference is not payment or trading authority. Initially, reward funding and securities orders each receive customer confirmation; later bounded automation requires an approved separate mandate.

Simplicity must not become concealment. Issuer, provider, custody, legal rights, fees, price, restrictions, settlement status, and material chain/provider risk remain visible in plain language before commitment.

2. One simple customer model

Financial detail uses five nouns:

• Portfolio — everything the customer has grouped for one purpose;
• Bundle — the customer's chosen assets and allocation plan, with actual holdings in its disclosed subaccount/provider location; the existing Personal Basket model;
• Account — an inspectable container inside a Portfolio;
• Holding — an asset or cash position;
• Automation — a customer-approved rule with an amount, scope, and end condition.

Infrastructure terms are not primary navigation or required onboarding knowledge:

• Canonical Account;
• Account Instance;
• Account Mirror;
• root router or Mirror Controller;
• mandate epoch, nonce, configuration hash, adapter, or message bridge;
• ERC-1271, ERC-4337, CAIP-2, calldata, or selector.

These terms remain available in an advanced technical view, support export, and audit record. Customer-facing language uses Account, Network Account, or Provider Account only when the distinction is material.

3. Progressive disclosure

Every flow uses four disclosure levels:

No required fact may exist only in Advanced. No infrastructure term should appear in Primary unless the customer must act on it.

4. Account orchestration behind the interface

Forage maintains the canonical hierarchy defined in the account and mirror system, but exposes it as one Account experience.

When the customer creates an Account, Forage may automatically:

1. create the Canonical Account record;
2. select an eligible provider and network from an approved capability matrix;
3. deploy or request the required Account Instance;
4. bind the provider wallet/account;
5. prepare gas sponsorship or required funding;
6. reconcile provider, chain, and Forage records;
7. present one completion state.

Automatic selection is allowed only when the options are economically and legally equivalent under an approved deterministic policy. Forage must ask the customer when a choice changes price, fees, legal rights, custody, liquidity, tax treatment, transferability, settlement time, or material risk. AI never makes or silently changes that choice.

5. Unified action model

The same interaction pattern should handle buy, sell, fund, withdraw, rebalance, and automate:

Choose action
  -> enter intent
  -> Forage resolves eligible route
  -> review exact result and authority
  -> confirm once
  -> observe one durable status

Avoid chain switching, manual address entry, token approvals, gas-token acquisition, bridge selection, provider reauthentication, and multiple signatures where the selected provider and wallet stack safely permit abstraction. When an additional step is unavoidable, explain why, preserve progress, and return the customer to the same flow.

Bundle trading includes buying the composition, adding money, selling a fraction or selected holdings, selling all eligible holdings and explicitly rebalancing toward changed targets. Editing a plan alone does not trade. The holdings remain in the customer's actual subaccount or disclosed provider account. An independent custody boundary is never implied for a mere accounting label.

One review does not guarantee one atomic transaction. Before a multi-order bundle, show fees, minimums, potential partial completion and the recovery policy. One parent status summarizes actual leg outcomes; Partially completed must remain distinct from Settled. A blocked constituent does not make a full-exit claim true.

6. Status and failure handling

Home distinguishes Discounts used, Pending rewards, Available rewards, Income accruing, and Holdings. A discount is not spendable cash. An estimated accrual is not withdrawable income. Portfolio value excludes pending commissions, mirror budgets and promotional credits. It includes each holding's current value once; income already reflected in a fund's NAV is never added a second time. Each amount links to its provider, source and availability terms.

Income can accrue while the app is closed. Show the provider's distribution schedule and the rate's measurement type; never require a daily claim to earn it. Market gains and earned income use separate labels. Cash deposits and investments do not share an insurance or principal-protection claim.

The customer's economic result is central. Deposits, gross sale proceeds and internal transfers are not earnings. Reward funding into a bundle is an external contribution for that bundle's investment-return calculation. Income, cost basis, realized/unrealized P&L and fees reconcile without double counting. Negative net results are as visible as positive cash income.

For funding and investment actions, the customer sees a normalized lifecycle. Merchant rewards instead retain their specific Pending, Approved-awaiting-payment, Available and payout states:

Needs review -> Ready -> Processing -> Settled
                         -> Needs attention
                         -> Cancelled / Expired

Technical states such as API accepted, signature requested, submitted, soft-confirmed, provider executed, chain finalized, and reconciled remain internally distinct. They appear as a detailed timeline, not as competing primary statuses.

Every failure message must state:

• what happened in plain language;
• whether funds or holdings moved;
• whether anything is still pending;
• what Forage is doing automatically;
• the one action, if any, required from the customer;
• how to inspect technical evidence or contact support.

The interface never asks a customer to retry an ambiguous value-moving action until idempotency and reconciliation prove that a duplicate cannot occur.

7. Automation experience

An Automation is described by outcome and limits, not session-key machinery. The activation review shows:

• what may happen;
• which selected holdings or cash it may use;
• maximum per action, period, and lifetime amounts;
• frequency and permitted hours;
• price and slippage limits;
• start, expiry, pause, and stop conditions;
• whether Forage or an external provider submits the action;
• how to pause and revoke it.

The default security screen offers Pause and Revoke. Advanced details expose delegates, Account Instances, sessions, epochs, and policy hashes. A customer never has to revoke several hidden technical objects manually; one Forage revoke flow coordinates every layer and reports partial completion explicitly.

8. Non-negotiable experience rules

• One task should have one obvious primary action.
• Ordinary customers should not need a gas token, chain ID, contract address, bridge, or wallet-network switch.
• Account creation should not ask customers to choose an account implementation.
• Provider and network selection are automatic only within an approved equivalence class.
• A Portfolio total never erases provider, custody, instrument-rights, or settlement distinctions.
• Pending and settled value are visually and numerically separate.
• The product never says “complete” before provider and chain reconciliation meet the defined completion rule.
• No AI response, reward, social action, or engagement mechanic can alter routing or authority.
• Advanced controls remain discoverable; simplicity is not loss of customer control.
• Accessibility, mobile completion, keyboard navigation, and understandable error recovery are release requirements.

9. Acceptance metrics

The full financial release must prove customer-created bundle purchase, holding, additions, partial/full sale, explicit rebalance and eligible proceeds withdrawal. Neither a merchant-only pilot nor a one-asset demonstration completes the bundle product. These customer-mediated actions do not depend on later background automation. The bundle release requirements govern acceptance.

Before each financial capability is enabled, usability testing must demonstrate its applicable outcomes below. The merchant-only pilot instead proves discovery, terms comprehension, source-specific claim status, funded redemption and recovery without financial enrollment; it does not require an Automation or funded brokerage account.

For the corresponding financial releases, representative customers must be able to:

1. explain what they own and who provides/custodies it;
2. fund an Account without manually locating a chain or contract address;
3. understand the full cost and expected settlement state before confirming;
4. distinguish pending from settled value;
5. create, pause, and revoke an Automation without understanding session keys;
6. recover from an interrupted or failed flow without duplicating a transaction;
7. locate addresses, provider records, and technical evidence when asked.

Track completion rate, unnecessary abandonment, time to first funded Account, signatures per task, support contacts per task, failed recovery rate, duplicate-intent prevention, comprehension, and accessibility defects. Do not optimize these metrics by suppressing risk, cost, custody, or rights disclosures.

Also measure the first fulfilled merchant reward, matured reward-to-savings adoption, retained customer-directed contributions excluding market gains, useful trail shares, qualified referrals, reward payment time, and contribution after fulfillment, losses and support. Daily logins and securities order count are not the growth objective. Usability checks must include a customer who declines location access, a customer ineligible for equities, and a customer who wants only merchant redemption.