hunch.01 / Better decisions create repeat usage.
Hunch connects contract behavior, instrument meaning and market dependencies for agentic finance on Robinhood Chain. The proposed business model combines fleet subscriptions, included execution workflows, maintained evidence and operator support. Customers can use the service without buying a token.
Intelligence and execution APIs are live. The route dependency observer persists evidence independently of browser sessions. Paid plans, fleet monitoring and billing remain proposed; browser watchlists still refresh only while open.
02 / Earned usage revenue funds the intelligence.
Paid requests should produce identifiable usage receipts: what was delivered, its price, and the evidence timestamps. Better coverage, dependable data sources and measured correctness give operators a reason to integrate and keep using Hunch.
Unused prepaid credits are customer liabilities. Token-sale proceeds, deposits, borrowed funds and unrealized gains are excluded from service revenue used for this policy.
One workflow. Outcome-neutral pricing.
Proposed metering bundles preflight and its mandatory revalidation into one completed workflow. Valid policy blocks should cost the same as approvals; retries of the same request and provider failures should not create duplicate charges. Request idempotency, customer accounts and settlement reconciliation must ship before billing.
Hunch currently charges no route fee and receives no represented referral compensation. Venue selection should follow the customer mandate. Conditional Hookr rebates and unclaimed protocol balances are excluded from Hunch service revenue.
The operating loop is useful checks → repeated integrations → paid fleet workflows → better coverage and reliability → retained customers. This is a business hypothesis to measure through paid retention, cost per completed workflow and renewal, not simulated trading volume.
03 / Protect the service. Allocate the surplus.
Proposed policy: allocate 20% of eligible monthly operating surplus to HUNCH buybacks and burns, after refunds, fees, operating costs, tax provision and a three-month operating reserve. No surplus means no buyback allocation.
The remaining surplus supports the business and product. This proposal is inactive until the token, treasury, payment system and final policy are configured. No live buyback or burn is represented.
Test the unit economics.
Editable monthly planning assumptions in USD, not pricing, customers, revenue or forecasts. Delivery cost must include RPC, data rights, evidence retention and both preflight and revalidation. The starting scenario is deliberately illustrative.
Gross margin deducts variable delivery and delivery support. Operating result also deducts fixed costs, refunds, payment fees and tax provision. Break-even holds monthly support and fixed expenses constant and excludes tax; it is not a scale forecast. Reserve requirements use the scenario’s full monthly operating cost. Every token execution budget remains zero.
04 / A burn needs a receipt.
A future transparency record will distinguish collected revenue, earned revenue, costs, reserve top-ups, allocated budget, executed purchases and completed burns. Each execution needs a public transaction and a verified effect on the correct HUNCH contract.
A planned budget is not a completed burn. Sending tokens to an inaccessible address is not the same as reducing total supply; the published receipt must state the actual mechanism. No token price, yield, revenue share or redemption right is promised.
| Today | Status |
|---|---|
| Intelligence console / API | Live, free public access |
| Paid billing | Not enabled |
| Official HUNCH contract | Not published |
| Buybacks / burns | Not enabled |