Reviewed: September 5, 2026. Scope: merchant revenue, reward delivery, savings yield, tokenized-equity access, and programmable accounts. This is an implementation and commercial diligence review; provider documentation is evidence of a published capability, not an executed Forage agreement or a legal conclusion.
Read alongside the growth and rewards specification, reward economics evaluation, and rewards and income architecture. Those documents define the customer loop, budget assumptions, and ledger boundaries; this review determines which proposed integrations still need commercial or technical proof.
Decision
Forage's useful promise is turn everyday value into customer-owned savings and eligible investments. The integration plan should prove that promise with one working money route before multiplying networks or chains.
Recommended pilot: one market, one approved incentive-publisher relationship, a small set of prefunded local campaigns, one reward payout method, and one regulated investment-provider candidate. Test a complete path from a real qualifying purchase to funded reward to an eligible customer's separately authorized investment. If the final funding route is not accepted, offer the contracted reward redemption and describe investing as unavailable, rather than crediting fictional buying power.
Start card-linked and brokerage commercial diligence in parallel with the affiliate pilot. Broad merchant catalogs, chain deployments, public APIs, and sandbox success do not establish Forage distribution rights, customer eligibility, or usable settlement.
Evidence and account status
No executed provider agreement or production approval was established in this review. The statuses below mean not contracted / availability unverified in the repository; they do not assert that a founder has no existing external account. Before activation, the operations register must contain the executed counterparty, product, jurisdiction, payout route, restrictions, fees, and evidence owner.
| Candidate | Published capability verified | Forage decision | Unresolved commercial gate |
|---|---|---|---|
| Dinari U.S. partner program | Documented U.S. customer integration | First U.S. equity diligence candidate | Acceptance of Forage, eligible products/accounts, customer wallet, funding and rewards use case |
| impact.com / CJ / Awin / Rakuten Advertising | Publisher and advertiser-program infrastructure | Evaluate coverage; integrate one first | Merchant-level incentive and distribution approval, net rates, payout terms |
| Visa Offers Network | Explicit non-issuer publisher model | Start role and coverage diligence now | Merchant eligibility, enrollment design, minimums, payout ownership and destination |
| Cartera | Offer content and card-linked API services | Compare with VON as an aggregation route | Forage acceptance, cards, territory, commercial pricing and liability allocation |
| Kard | Offer/reward API with issuer-oriented credentials | Ask how a standalone loyalty publisher qualifies | Issuer/data partner requirements, card population and settlement route |
| Mastercard Offers for Publishers | Publisher-facing offers product is listed | Request product and role fit | Exact accessible service, market, enrollment and fulfillment model |
| Tremendous | Funded reward/payout delivery | Sandbox and use-case review candidate | Allowed payout methods, recipient fees, returns, business approval and investment destination |
| Amazon Incentives | Gift-card fulfillment | Optional later reward catalog | Commercial program approval, prefunding and distribution terms |
| AGW | Abstract wallet and scoped session model | Preferred root experience, with explicit instance authority | Production policy review and the actual provider/account validation path |
| xStocks / Ondo Stocks / Robinhood Jersey Stock Tokens | Tokenized investment products with restrictions | Separate eligible non-U.S. workstream | Distributor rights, investor eligibility, instrument rights and supported venues |
Publisher/network references: impact.com Partner marketplace, CJ developer portal, Awin partner categories, Rakuten publisher technical onboarding. Commercial stack references: Visa Offers Network, Cartera APIs, Kard API, Mastercard product catalog, Tremendous, Amazon Incentives.
Findings that change the plan
1. U.S. tokenized-equity access has a specific product boundary
Dinari's U.S. guide requires supplemental KYB/agreement, API v2, reviewed UX and communications, and dedicated wallets tied to verified brokerage accounts. It describes U.S. dShares as a secondary ledger of securities ownership; these tokens are currently nontransferable and unavailable for DeFi or wrapping. Its U.S. funding section names USDC as the supported settlement stablecoin, limits partner-operated funding facilitation to qualified licensed businesses, and marks white-label wallet service as coming soon. Dinari U.S. guide.
Implication for Forage: U.S. equity access is a contracted brokerage integration. A Forage mirror cannot make an otherwise restricted token tradable or portable. Do not promise a managed-wallet fallback, USD+ settlement, free-form transfer, or automated reward funding until the U.S. partner team confirms that exact flow.
The generic quickstart mentions managed/self-custody wallets, multiple funding tokens, and hosted trading. Those general features need region-specific confirmation. Hosted trading is worth evaluating if it materially shortens the approved ownership experience. Dinari quickstart.
2. Tokenized exposure and underlying share ownership are different
xStocks' partner page excludes U.S. persons and the U.S.; Ondo's current Stocks eligibility page also excludes U.S. participation and imposes investor restrictions in some other markets. The existence of liquidity on a permissionless chain does not establish permission for Forage to distribute those instruments. xStocks partner requirements, Ondo Stocks eligibility.
Robinhood's current Jersey-issued Stock Tokens are described as debt securities providing economic exposure without rights in the underlying issuer, and they exclude U.S. participation. Keep these separate from its Classic Stock Token derivatives and from a customer's actual brokerage equity ownership. Robinhood Jersey Stock Tokens, Classic Stock Token FAQ.
Forage's instrument record must preserve issuer, legal form, customer rights, jurisdiction, custody, settlement rail, redemption restrictions, and corporate-action treatment. Equivalent tickers never prove equivalent instruments. A location-based reward cannot bypass investor qualification, even when the reward is funded entirely by a merchant.
3. AGW removes repeated prompts within approved authority
Abstract documents AGW as a wallet for Abstract applications. Session keys permit scoped actions and require a security review and policy-registry approval on mainnet. These are distinct from a remote account's own validator and execution authority. AGW overview, session keys, production policies.
Dinari's Alchemy example demonstrates ERC-1271 smart-wallet signatures and an externally signed order path; it does not prove that a Forage account owned by AGW on another chain is accepted. Dinari smart-account example.
Keep AGW as the root experience, preserve independent Account Instances, and prove the exact wallet-link, order-permit, recovery and revocation lifecycle. A remote owner path must authenticate an Abstract-root intent or use an explicitly authorized local validator. Reusing the Abstract AGW address on another chain is not that proof. Mirrors carry bounded control state; customer holdings remain at their authoritative provider/chain account. ERC-6551 remains excluded.
4. Cashback is a supported publisher category, with specific approvals
Awin distinguishes cashback, loyalty, and virtual-incentive publishers; advertiser acceptance is still part of the cashback workflow. impact.com's missed-action inquiry feature also requires support enablement for cashback/loyalty partners. Build the exact declared business model into applications and missing-reward support. Awin categories, Awin cashback, impact.com action inquiries.
Awin's current affiliate-partner page says joining is free. The old checklist's assumed verification deposit has been removed; regional terms still need confirmation. Amazon Associates' standard policy prohibits rewards for use of affiliate links; Amazon gift-card inventory from a fulfillment service does not create permission to use Associates traffic in a loyalty model. Awin affiliate partners, Amazon Associates policies.
Do not expose every feed item. Publication requires a valid approval intersection: Forage company + advertiser + promotional property + incentive method + channel + territory + current offer terms. Disable the offer when any required element expires or is revoked.
5. Card-linked deals deserve early commercial evaluation
Visa Offers Network explicitly accommodates approved non-issuer publishers and configurable fulfillment, including statement credits. Cartera advertises card registration and transaction matching. Their public documentation does not establish a universal minimum scale for Forage. VON onboarding, Cartera APIs.
A statement credit reduces the customer's card bill; it is not a cash deposit to Forage or a brokerage. Ask separately whether Forage receives a commission payout, controls reward issuance, or merely reports a benefit supplied by the network. Existing card programs can also affect reward eligibility; Kard documents that another program may make a user ineligible. Kard API.
Recommend one card-linked partner only when approved local coverage and conversion benefit justify fixed costs and enrollment friction. Do not issue a card just to imitate a card-linked product. Do not assume a publisher can enroll arbitrary cards through an issuer-only API.
6. Daily yield is a separate customer product
Dinari describes USD+ as Treasury-backed with daily rebases, while its integration guide describes redemption requests that may take up to three days. That combination demonstrates why daily accrual and immediately withdrawable cash must be modeled separately. It does not establish USD+ eligibility for Forage's intended customers. USD+ description, USD+ redemption integration.
Forage should evaluate a provider-approved savings or cash-management product for each market. Record source of return, customer eligibility, legal instrument, fees, rate method, accrual calendar, distribution schedule, liquidity, loss risk, custody, and protection claims. Leave the yield product unselected until the provider confirms these facts. U.S. brokerage enablement alone does not approve a separate yield token or savings service.
Product language can promise daily visibility only when the data supports it. Label estimates, accruals, distributions and available cash separately. A daily display does not imply a fixed rate, a daily equity dividend, positive returns every day, or immediate redemption. The customer does not need to claim a daily reward or keep an app streak to receive yield that belongs to them.
One reward does not represent all kinds of value
| Value | Authoritative record | What the customer can use it for | Can it fund Forage campaigns? |
|---|---|---|---|
| Discount | Merchant receipt and offer terms | Lower eligible purchase price | No cash is created by the discount itself |
| Network commission receivable | Contract and approved transaction report | Nothing until Forage funds a corresponding reward | No; it is not liquid reward backing |
| Available customer reward | Liability ledger plus settled reserve or funded advance | Only contracted redemption methods | No; it is already owed or reserved |
| Customer savings principal and yield | Customer's provider account and statements | Customer-directed uses allowed by that product | No automatic access or cross-subsidy |
| Customer equity holding/distribution | Brokerage/provider and instrument records | Eligible customer actions | No |
| Unrestricted earned Forage revenue | Protocol operating ledger | Operating costs and explicitly allocated budgets | Yes, only after liabilities and reserves are covered |
| Protocol treasury investment return | Protocol-owned asset account | Treasury use after realization and restrictions | Only distributable, realized surplus; never projected appreciation |
Every adapter must report actual currency/asset and recipient. Cash payout, gift card, credit, points, and a token cannot be normalized into an undifferentiated spendable dollar balance. Displayed savings are not portfolio cash. Customer principal and customer yield remain outside protocol reward funding, including any future token or BURR distributions.
Money routes to qualify
| Proposed route | Current status | Evidence needed before activation |
|---|---|---|
| Merchant discount -> reduced checkout price | Feasible candidate; no Forage merchant agreement verified | Redemption terms, stackability, merchant invoice/receipt validation |
| Approved commission -> Forage bank -> funded reward payout | Feasible candidate; not contracted | Commission settlement, merchant incentive permission, fulfillment acceptance, funding and reversal test |
| Card-linked reward -> statement credit | Published candidate capability; Forage availability unverified | Supported card enrollment and credit confirmation; no claim that the amount is investable cash |
| Reward -> customer-owned bank -> separately funded brokerage account | Fallback to evaluate | Payout account ownership, provider ACH acceptance, fees, timing, customer consent and reconciliation |
| Reward -> broker account directly | Unverified | Both parties' written acceptance of third-party reward funding, beneficiary mapping, rail, limits and return handling |
| Reward -> USDC -> customer/provider wallet -> broker | Unverified | Approved settlement chain/token, payer and source-of-funds acceptance, conversion fees, licensing responsibilities, failure recovery |
| Gift card / discount / statement credit -> automatic tokenized stock | Unsupported assumption | No automatic conversion is proposed; a separate cash source and approved order would be required |
| Customer yield -> optional customer-selected recurring investment | Unverified | Product eligibility, realized availability, mandate, provider automation permission, minimum order and cost test |
Tremendous lists bank, wallet-service and gift-card payout options and provides a sandbox. That is fulfillment capability; Forage supplies the money. Its catalog is not evidence of merchant-funded economics, crypto settlement, or acceptance of a brokerage destination. Tremendous API.
Partner diligence packet
Use a diagram showing named legal parties, money direction, custody, currency, account ownership, and reversal responsibility. Attach the exact customer screens and proposed incentive/referral terms. Ask for written answers, named owners, prices, and a test plan.
| Counterparty | Questions that change the launch decision |
|---|---|
| Affiliate network and advertiser | Is this mobile cashback/game-discovery property accepted? Are fixed referrals, sharing, teams, codes, receipts, and creator traffic permitted? Which specific merchants and markets are available? Can users be identified with permitted opaque attribution IDs? What causes rejection or later clawback? What are lock, payment, minimum and dispute timelines? |
| Card-linked provider | Can Forage operate without issuing cards? Who supplies authorized transaction data and hosted enrollment? Which networks/cards/territories work? Does enrollment conflict with another rewards program? What does Forage receive in money versus status notifications? Who pays the reward and to whom? What are fixed fees and exit obligations? |
| Fulfillment provider | Does the reward/investment-adjacent use case qualify? What recipient methods, fees, minimums, funding delays and reversals apply? Are beneficiary-owned bank and brokerage accounts accepted? Are crypto payouts supported under this exact agreement? How are ambiguous, expired, unclaimed and returned payments reconciled? |
| Dinari / brokerage provider | Is Forage's exact role and compensation model accepted? Which states, customers and products qualify? Are rewards-funded accounts and recurring customer-authored orders allowed? Which wallets, chains, validators and recovery flows pass review? What cash/yield product, if any, is separately available? Who accepts ACH and third-party rewards? What are all data, account, order and support costs? |
| Savings/yield provider | Who owns the principal and return? What creates yield and can the rate become zero or negative? When is it accrued, distributed and available? Can withdrawal be delayed? Which customers can hold it? What asset, issuer, custody, redemption and protection language is correct? Can the customer authorize onward investment without surrendering withdrawal control? |
| Abstract/account provider | What review and production registry entry is required? Can this exact root/instance validator design work? Which chain is authoritative for each signature? How do recovery, offline exit, module changes, delegates and delayed revocation work? |
No provider marketing claim replaces a response about Forage's exact legal entity, customer population and funds flow. A sandbox that permits an action is not evidence of production permission.
Implementation acceptance tests
These are required test cases for the future integration, not claims that production code exists:
- One customer, approved offer and source event create exactly one pending reward; duplicated and reordered webhooks do not increase liability.
- Commission confirmation without received cash never creates available customer value unless a funded Forage advance is explicitly reserved.
- A funded payout reserves its amount before submission; timeout/retry reconciles the external reference and cannot pay twice.
- A purchase return after payout creates a compensating commission/reward entry and consumes the proper Forage reserve, without accessing customer savings or securities.
- A denied offer or reward payout leaves customer-owned funds and progress intact; support can explain the exact terms and next action.
- Discounts and statement credits never appear as brokerage cash. Broker buying power is reconciled with provider-confirmed funds.
- An attempted prohibited token route fails before quote or signature; eligibility is checked for the customer, instrument, provider and destination, not just the chain.
- A broker account is bound only to the correct dedicated wallet; an AGW address on a remote chain cannot impersonate the root authority.
- Delegation revocation, stale mirror messages, delayed provider events and owner recovery preserve local budget limits and never duplicate holdings.
- A yield rate drop to zero, delayed redemption and corrected accrual do not create a protocol deficit or reduce an earned merchant reward.
- A shared offer cannot create multi-level commissions, self-referral rewards, or more fixed claims than the campaign's reserved cap.
- The first signed production pilot reconciles merchant evidence, provider reporting, bank movement, reward liability and customer receipt before scale increases.
Commercial release gates
Discovery-ready: truthful publisher pack, named legal entity, geography, intended reward form, preliminary pricing, and a merchant shortlist with actual channel fit.
Rewards-pilot-ready: one executed approved publisher/campaign relationship, one accepted funded payout rail, bounded liability, fraud controls, customer terms, and a successfully reconciled end-to-end reward including a reversal scenario.
Ownership-pilot-ready: customer/instrument approval, signed regulated-provider terms, reviewed product flow, dedicated accepted account/wallet, funding compatibility, and successful customer-mediated purchase and reconciliation. The reward transfer is a separate gate even when the securities integration is approved.
Daily-yield-ready: separately approved product and customer eligibility, correct rights/risk language, verified accrual and redemption behavior, provider data, and customer authority. Projected yield never backs an already promised reward.
Expansion-ready: repeat use, positive contribution after variable costs, funded acquisition budgets, merchant incremental-value evidence, and acceptable reversal/support rates. Add a second network or chain for a demonstrated customer need, using instrument and authority compatibility tests rather than asset-count targets.
The publisher onboarding runbook contains account ownership, readiness and operating checklists. The account and mirror specification remains authoritative for holdings and authority; the responsible engagement system controls game mechanics around customer finances.