Skip to content
forage.
← All resources

Under the surface

Delivery roadmap

Evidence gates for the first financial release, Clubs, automation and more networks.

September 5, 20266 min read
Product direction. Not a live offering.

Financial capabilities, provider access and coverage require separate approvals. Examples are illustrative, not promises of returns.

Updated September 5, 2026. The core release is earning money plus creating, holding and trading personal asset bundles in customer subaccounts. The earning and bundle specification controls that priority and acceptance. Phases are evidence gates, not calendar promises. Merchant discovery supports the core product; a merchant-only pilot is not its completion. The rewards/income architecture defines money flows.

Current implementation reality

The unified thesis now includes social Bundles, managed Forage Clubs, trader-funded risk sharing and Harvest. These are accepted product pillars with distinct release gates, not live capabilities or prerequisites that postpone the complete self-directed financial release.

Present: standalone monorepo, Next.js public/terminal/design-system shells, Railway API health/platform routes, shared packages, audit/idempotency table primitives, Foundry-ZKsync configuration, sentinel contract and specifications.

Not implemented or proven: publisher integrations, customer auth, reward accounting, payouts, income provider, securities orders, account provisioning, live AGW mandates, mirrors or production money-moving contracts. Code still contains @wry/* branding, a Wry platform response, portfolio-scoped placeholder mandates, integer-only satellite chain identifiers and an obsolete IPortfolioVault proposal. These require migration before production. Contract/toolchain availability and provider access require separate verification.

Phase 0 — commercial and product proof

  • Finalize entity, domain ownership, company accounts and truthful publisher profile.
  • Choose one launch area, adult cohort and initial merchant categories.
  • Secure one primary affiliate network and individual merchant approvals; recruit 5-10 direct merchants with bounded prefunded campaigns.
  • Start card-linked commercial diligence in parallel; implement when coverage and terms justify it.
  • Seek one U.S. income-product route and a conventional cash fallback; verify embedded access, funding, fees and redemption.
  • Validate Dinari partner fit, dedicated wallet, USDC funding and reward-to-broker route.
  • Prototype earnings-led Home, My bundles in Portfolio, and create/buy/hold/add/sell/rebalance journeys alongside supporting Explore offers.
  • Replace illustrative economics with contracted costs and a funded operating/acquisition plan.

Gate: one viable merchant offer, named fulfillment route, positive contribution after attributable costs, bounded liabilities and a credible path to eligible ownership.

Phase 1 — earning and bundle proofs in parallel

  • Normalize public naming and domain schemas; preserve historical references as needed.
  • Implement auth, consent, offers, terms versions, tracked claims, balanced reward journal, campaign reservations and private payout workers.
  • Reconcile one full collection, reward payment and reversal lifecycle.
  • Ship location-optional web discovery, planned-purchase lists, illustrated passport and shareable trails.
  • Separate demonstration values from real customer activity.
  • Provide support, dispute handling and campaign stop controls.
  • In parallel, implement bundle drafts, explicit provider/subaccount bindings, available cash/unit reservations, parent intents and order legs in the provider sandbox.
  • Prove customer-mediated multi-asset purchase, holding reads, addition, partial/full sale and rebalance before background automation.
  • Track actual allocation versus edited target plans, partial fills, net proceeds, cost basis and income attribution.

Gate: the merchant pilot proves funded rewards and redemption; the financial sandbox proves the bundle lifecycle and isolated custody/accounting. These tracks can progress independently. Only the subsequent approved financial release fulfills the full product.

Phase 2 — core release: earn, hold and trade bundles

  • Integrate an approved income account with explicit enrollment, actual rates, accrual/distribution records and withdrawal timing.
  • Build Equity Graph, Asset Passports, rights-preserving positions and corporate-action reconciliation for one provider.
  • Implement verified Legal Accounts, dedicated Account Instances and exact provider bindings.
  • Prove one customer-approved reward funding route and the full eligible multi-asset bundle lifecycle: create, buy, hold, add, sell part/all, explicitly rebalance and withdraw settled proceeds.
  • Make actual holdings, cash rewards/income, costs and realized/unrealized investment result prominent; deposits and gross sale proceeds never appear as profit.
  • Check minimums, fees, identity mismatches, conversion failures, partial fills and stale quotes.
  • Provide cash/merchant redemption alternatives when investments are unavailable or uneconomic.

Gate: customers can earn supported proceeds and hold/trade their self-created bundles in the actual disclosed subaccounts/provider accounts. A single-asset demo or merchant-only release does not pass. Income and equity availability are assessed independently; variable returns and partial completion remain clear. Background delegation and broad cross-chain execution are later conveniences, not prerequisites for user-mediated trading.

Phase 3 — repeat use and measured sharing

  • Add private groups, shared guides, repeat offers and fixed prefunded referral campaigns.
  • Add reviewed, versioned social Bundle plans and Club discovery with explicit publication/privacy choices; imports create inactive drafts, not trading authority.
  • Prove manual Harvest from eligible available funds and settled proceeds through approved routes, with transfers and investment profit reported separately.
  • Test neighborhood request boards using consented aggregate planned demand.
  • Compare outcomes against non-game and non-bonus cohorts.
  • Measure qualified/retained referrals, reward-funded saving, mature cohort contribution, acquisition payback, payout delay and merchant renewals.
  • Add one card-linked provider if coverage and retention benefits justify the servicing cost.

Gate: growth survives without indefinite subsidy, funded rewards remain usable and merchants have a reason to renew. Invite count is not proof of virality. Financial-account adoption never authorizes rewards for trading.

Phase 4 — bounded automation

  • Complete account-domain migration, threat model, directory and local programmable-account specifications.
  • Prove independent balances, allowances, nonces and epochs; implement narrow gateway/adapters.
  • Verify provider wallet validators and AGW production policy registration.
  • Add one customer-authored capped, expiring purchase/reinvestment mandate where permitted.
  • Keep funding/withdrawal permissions separate from reward preferences.
  • Verify isolation, quote limits, pause/revoke/recovery, concurrency and reconciliation with contract and provider tests.

Gate: independent security review, accepted provider actions, operating recovery evidence and small initial limits.

Managed Clubs workstream — accepted, separately gated

Commercial and legal design can progress in parallel with the core product. Execution cannot launch before the relevant account, provider and bounded-authority evidence above passes. Social membership and self-directed plan remixes do not depend on managed enrollment.

  • Establish the operator/adviser structure, provider/custody agreements, customer eligibility and permitted compensation. Do not assume universal retail performance fees.
  • Admit vetted operators with inspected strategy histories and conflict controls; use isolated customer-owned STRATEGY instances and approved liquid assets/venues, without initial leverage.
  • Prove no arbitrary execution or sibling access, valid economic outputs, capacity limits, malicious-price defenses, pause/revoke/recovery and partial-fill reconciliation.
  • Publish factual operator track records with fees, drawdowns, failures and data limits; separate operator reporting from customer privacy and reserve reimbursements.
  • Before advertising any bond or loss reserve, finalize its legal scope, independently controlled backing, uniquely reserved caps, periods, exclusions, claims, early exits, valuation disputes and collateral-release tests.
  • Stress simultaneous losses, operator/collateral failure, collusion, double claims and fee holdbacks. Pilot size is bounded by approvals, liquidity, operations and funded coverage capacity.
  • Preserve usable customer exits and accepted claim rights when pausing new enrollments. A customer stop does not erase fills or guarantee instant settlement.

Gate: the Clubs and Harvest specification is implemented and independently reviewed for the exact operator, strategy, jurisdiction and coverage terms. Conduct bonds and ordinary market-loss coverage are separate; neither implies guaranteed returns. Automated Harvest and early-stage deal access require further, distinct acceptance.

Phase 5 — providers and networks

  • Add one separately eligible non-U.S. lane at a time.
  • Prove raw/display units and corporate actions before basket execution.
  • Keep personal baskets as customer-owned direct constituents.
  • Test one mirror with authenticated messages, local expiry, independent delegates and preallocated budgets.
  • Prove replay, reordering, freeze/reallocate and outage recovery.
  • Keep provider transfer restrictions authoritative.

Gate: an additional network provides measurable benefit exceeding its cost, with independent asset and authority reconciliation. Mirrors never make restricted securities transferable.

Deferred work

Protocol token emissions, BURR accretion, randomness contracts, prizes, broad AI execution and onchain rewards escrow are outside the launch path. Realized unrestricted surplus may support a separately evaluated treasury policy after customer obligations, reserves and operating runway. Historical token allocations are not current reward funding policy.

The platform can make merchant discovery fun without increased securities turnover, forced deposits, pooled savings or transferable account ownership.

You’ve reached the end.Keep exploring

References to supporting material outside this public library are shown as text, not broken links.