Earn as a Builder Kit

The TradeOS Public Intelligence Kit is the open-source distribution surface for builders who want to earn on top of TradeOS by putting TradeOS public evidence into paid services, apps, bots, dashboards, agent workflows, vertical products, research products, and validation systems.

TradeOS is the crypto-market vertical of a broader source-grounded data intelligence strategy. Builders should treat it as an intelligence layer they can package into workflows, not as a hosted broker, managed account product, or execution platform. See TradeOS Business Thesis for the public business framing.

Repository: agenticsrclab/tradeos-public-intel-kit

Builder-facing setup, SDK, CLI, MCP, app-key, feedback-provenance, and paid boundary docs are mirrored in that public kit. The canonical TradeOS lifecycle reference for credits and app reputation is Data Intel Credit Loop.

TradeOS hosts the public-intelligence API. Builders run their own products, workers, MCP servers, dashboards, or bots and point them back to TradeOS for the public evidence layer. Builders bring their own LLM provider when they want model summaries. Venice AI is the default OpenAI-compatible provider in the kit, so inference cost stays with the builder or their users instead of being subsidized by TradeOS.

The flagship product shape is an individual private-use, self-hosted TradeOS Symbol Cockpit: enter a symbol and receive the good, bad, ugly, verdict, evidence, confidence, and action recommendation. Builders can package or extend the cockpit for users to self-host. The self-hosted operator keeps watchlists, local memory, strategy notes, wallet context, bot rules, exchange keys, approval policy, and logs private unless they choose to send feedback or authenticated context to TradeOS.

That private model is the point:

TradeOS Data Intelligence OS = intelligence products, evidence, data, feedback targets
Symbol Cockpit Agent = private local recommendation and decision runtime
Future local modules = feasibility, EA/risk, execution adapters, ops dashboard

The builder value ladder is:

Use TradeOS free.
Earn Data Intel Credits by improving intelligence quality.
Build and earn on public intelligence.
Pay when you need private intelligence, scale, alerts, automation, or data rights.

For builders, that means the public kit should be useful before payment, app keys should preserve attribution when feedback comes back, and paid TradeOS should begin when the product needs private intelligence products, production volume, delivery, automation, machine access, or explicit data rights.

Why the data layer matters

The public kit is valuable because it gives builders a source-grounded market intelligence layer before they build the workflow around it. Without that layer, a bot, dashboard, digest, or private cockpit can still look polished but fail on the parts users actually need to trust:

Missing layer	Builder failure mode	User cost
Token identity	The product routes a symbol to the wrong asset.	Copycat-token confusion and bad watchlists.
Freshness	The product repeats old evidence as current.	Late alerts and stale recommendations.
Source evidence	The product cannot show why an answer was produced.	Lower trust and harder review.
Risk context	The product omits caveats around liquidity, sellability, or uncertainty.	Unsafe action framing.
Feedback IDs	The product cannot send useful labels back to TradeOS.	No compounding intelligence quality.

See Problem Space for the broader cost of missing TradeOS-like data and why source-grounded intelligence is the foundation for builder demand. The useful anchor is exposure, not a guaranteed ROI claim: manual review drag can become a six-figure annual cost, stale context can expose six- or seven-figure workflows, and an under-sourced product can lose recurring revenue when customers stop trusting it.

What the kit gives builders

The kit is designed to help a builder prove a real workflow before committing to custom data pipelines or paid enterprise integration.

Surface	What it does	Useful for
Public-intelligence API	Reads TradeOS public market intelligence and accepts attributed feedback	Apps, dashboards, bots, research tools
JavaScript SDK	Typed client for Node and TypeScript apps	Web apps, workers, bot services
Python SDK	Lightweight client for research and data workflows	Notebooks, validation scripts, quant prototypes
MCP server	Agent tools for reading public evidence and writing feedback	Claude Desktop, Cursor, local agent hosts
CLI agent	Command-line market digest and ask flows	Demos, cron jobs, research workflows
Symbol cockpit pattern	Turns a symbol into good/bad/ugly verdicts and trade/action recommendation cards	Private trader tools, bot preflight, watchlist intelligence products
Action intent contract	Non-executable action context that requires operator review before paper/local workflows	Review queues, policy gates, paper trading, independent executor experiments
Market briefing bot	Source-backed briefing worker	Discord, Telegram, community channels
Examples and docs	Setup paths, feedback provenance, paid boundaries, safety notes	Faster builder onboarding

The public kit can help builders produce actionable recommendations, but it is not a TradeOS-hosted exchange connector, custody system, managed-account service, or order router. Its job is to provide evidence, context, target IDs, caveats, and feedback paths that private self-hosted products can turn into buy, sell, trim, avoid, watch, or pass recommendations under the operator's own rules. Builders should not operate the cockpit as a shared managed account service, collect customer exchange credentials, custody customer assets, control customer accounts, or place orders for customers.

Action intents are the bridge from recommendation to operator workflow. They are non-executable, require operator review, and must not include venue, account, size, order type, route, calldata, transaction body, or execute URL fields.

Builder path

1. Start from the GitHub repo. Clone the public kit and run the CLI or market briefing bot against TradeOS public evidence.
2. Open the Builder/App Feedback portal when attribution matters. Use Builder/App Feedback to inspect app reputation DTI and feedback status, then use Developer Keys from that portal to create a public-intelligence key for a real app, bot, or workflow. Verified keys immediately enter the 7-day starter quota window.
3. Configure the public API base. Production integrations should target https://api.tradeos.tech/v1/public-intel.
4. Bring an LLM key only when needed. The kit can produce deterministic briefings without an LLM. When a builder wants richer language, they can set a Venice API key from the Venice AI subscription page or another OpenAI-compatible provider.
5. Preserve target IDs. Store the digest, thesis, evidence card, watchlist, or answer IDs shown by TradeOS so feedback can be attached to the exact public object that users saw.
6. Submit feedback with provenance. Distinguish human, human-assisted, agent, and automation feedback so TradeOS can learn from it without treating every label as verified human judgment.
7. Upgrade when the workflow needs production depth. Paid TradeOS surfaces are for private intelligence products, scale, automation, history, alerts, exports, x402 machine access, or enterprise data arrangements.

API quota and review policy

The public API follows the same product logic as the GUI credit loop: try it free, send useful feedback to stay useful, request review for a real project, and pay when the workflow needs scale or premium rights.

Default public-intel API quotas are intentionally conservative:

Profile	Reads/min	Reads/hour	Reads/day	Symbols/day	How it refreshes
Anonymous preview	2	15	40	5	Keyless public preview only
Builder baseline	5	50	100	10	Default after starter expiry
Builder starter	15	150	400	30	Verified app key for 7 days
Builder earned	15	150	400	30	At least 5 useful feedback events in 7 days with low suppression
Reviewed project	30	300	800	60	Operator-approved app after quota request
Limited app	5	50	100	10	Reputation or operator review reduced the app

Default write limits are also bounded: app-key feedback/write events are 10/minute and 100/day; anonymous feedback/write events are 5/minute per IP.

To request more public quota before buying, submit a project review from a verified TradeOS account:

POST https://api.tradeos.tech/v1/public-intel/quota-requests

The request should describe the project, app key, expected daily reads, expected symbols per day, monetization plan, feedback plan, and whether the builder is evaluating paid access. Approval is manual. TradeOS can approve reviewed-project quota, keep the app on baseline, limit abusive usage, or move the builder to x402/entitlement for paid scale.

App keys provide attribution and reputation. They are not paid entitlements. Data Intel Credits use one common unit with scoped spend rules: human DTI unlocks public dashboard depth, public Ask packs, or Review Lab access where TradeOS enables it, while builder feedback affects app reputation and quota confidence. Human DTI is not API-convertible and does not unlock bulk exports, historical replay, machine-scale reads, alerts, webhooks, private intelligence context, execution, custody, or enterprise data rights.

Builder and agent feedback is visible as app_reputation_dti on app-key and admin responses:

GET https://api.tradeos.tech/v1/public-intel/api-keys
GET https://api.tradeos.tech/v1/public-intel/app-attribution
GET https://api.tradeos.tech/v1/public-intel/admin/app-ops

Builders and agents can inspect individual feedback lifecycle rows:

GET https://api.tradeos.tech/v1/public-intel/feedback-activity
GET https://api.tradeos.tech/v1/public-intel/app-feedback-status

Use feedback-activity from a signed-in builder account to see app-key feedback owned by that account. Use app-feedback-status from an agent, bot, MCP server, or self-hosted app with its public-intel app key to self-check accepted, pending, rejected, or suppressed feedback. The activity rows expose lifecycle status, target IDs, source/agent metadata, and app reputation DTI effect; they do not mint personal human DTI and do not unlock paid capacity.

Viewer boundaries are strict:

Caller	Expected result
Signed-in builder account	Can inspect only app keys owned by that account. Unowned key_id values are rejected.
Agent or app key	Can inspect only the authenticated app key. Missing, invalid, revoked, suspended, or expired keys are rejected.
Human credit dashboard	Shows personal human DTI only. Agent/app reputation DTI is not added to the human credit balance.

The lifecycle is:

1. The app or agent submits feedback with a valid app key, stable target ID, feedback source, automation level, and optional agent run metadata.
2. TradeOS writes a pifb_... row in the public-intel feedback ledger.
3. Feedback Ops or autonomous Feedback Ops approves, rejects, or routes it to a review task.
4. Accepted and unsuppressed eligible feedback increases app_reputation_dti.earned.
5. Pending eligible feedback appears in app_reputation_dti.pending.
6. Rejected or suppressed eligible feedback appears in app_reputation_dti.revoked.

Valid app-key agent feedback is app-reputation credit, not a personal balance:

{
  "credit_class": "app_reputation_dti",
  "personal_balance": false,
  "api_convertible": false,
  "paid_capacity_unlocked": false,
  "human_dti_created": false
}

Raw automation feedback is stored as telemetry and shown in automation counts, but it is zero-weight for earned app reputation until it is trusted by policy. Production scale still requires x402, paid API, contract, entitlement, or an operator grant.

The important builder rule is: public-intel API feedback proves app quality and can improve quota posture; it does not create a personal human credit balance. Human DTI belongs to the signed-in TradeOS user's GUI/review loop. App reputation DTI belongs to the builder app key.

At launch, each free public API read is counted as one read unit. Weighted public read accounting is not enabled yet; batch, history, export, and machine-scale surfaces remain paid/x402 or entitlement-gated.

Free API access is best-effort and may be rate-limited, changed, paused, degraded, or revoked to protect TradeOS infrastructure. The free public pool is capped separately so paid/x402/contract capacity can be preserved.

How builders earn

The most useful builder products package TradeOS public evidence into a workflow that saves time, improves trust, or gives users a repeatable review habit.

The table below is a starter map, not a limit. Builders can package their own services, workflows, vertical apps, private dashboards, agent skills, monitoring packages, concierge research, or domain-specific automation when the offer is source-grounded, supportable, and clear about TradeOS safety and paid-access boundaries.

Product	Who pays	What the builder sells	TradeOS upgrade trigger
Private self-hosted symbol cockpit and action agent	Active traders, token teams, research desks	Local buy/sell/trim/avoid/watch recommendations, watchlist scanners, recommendation inbox, bot preflight, private control plane	Alerts, private intelligence context, larger universes, premium history
Research digest	Traders, analysts, funds, communities	Edited briefings, archive, member access, source links	More volume, custom universe, paid Market Pulse
Community bot	DAOs, token communities, trading groups	Discord or Telegram commands, scheduled summaries, feedback capture	Higher read volume, team access, hosted delivery
Watchlist monitor	Active researchers and token teams	Saved lists, change tracking, alert workflow, dashboard seats	Alerts, webhooks, custom watchlists
Tradebot intelligence layer	Bot builders and quant developers	Caveats, regime context, invalidation notes, post-trade review context	Automation-safe API, private forecasts, premium context
Quant validation workflow	Quant shops, funds, research teams	External labels, disagreement reports, replay and evaluation workflows	Historical datasets, regimes, outcomes, validation API
Claim and proof explorer	Analysts, creators, research desks	Public proof pages, outcome tracking, reputation workflow	Paid proof tooling, team analytics
Market context widget	Wallets, dashboards, data portals	Embedded public market state and evidence summaries	B2B widget/API subscription, paid entitlement

Builder flywheel

The business loop is intentional:

TradeOS exposes useful public evidence
  -> builders package paid services, workflows, agents, dashboards, or vertical apps
  -> customers use those builder products
  -> users, agents, and apps submit feedback through stable TradeOS IDs
  -> TradeOS improves coverage, ranking, caveats, confidence, and freshness
  -> better intelligence makes builder products more useful and differentiated
  -> successful workflows need paid TradeOS depth, x402, enterprise access, or data rights

Builders bring distribution, audience, workflow context, and domain expertise. TradeOS brings the intelligence layer, evidence contracts, feedback targets, paid depth, and data-rights boundary. Each turn should make both sides stronger.

Symbol cockpit and action agent

The simplest consumer story is:

Give TradeOS a symbol.
TradeOS returns the good, bad, ugly, verdict, evidence, and an action
recommendation.

Example output:

VVV: avoid new long.
Good: momentum improved and sector interest remains present.
Bad: fusion agreement degraded and liquidity depth is thin.
Ugly: flow stress is elevated during broader market risk.
Recommendation: avoid a fresh long; if already exposed, consider trim or tighter
risk controls until flow stress normalizes and fusion recovers.
Feedback: useful / wrong / late / missing context.

This should be framed as a private self-hosted recommendation and bot-preflight layer, not as a managed trading account or TradeOS order-placement system. The self-hosted operator owns execution, exchange keys, sizing rules, approvals, and local audit logs outside the public kit.

When the cockpit needs to hand a recommendation to a local workflow, use a non-executable action intent. The public kit can validate and display the intent, but live executors remain independent products outside TradeOS-hosted infrastructure.

Future open-source modules can extend the same local control plane:

TradeOS intelligence -> private cockpit -> local feasibility gate
                     -> local EA/risk gate -> optional local execution adapter
                     -> local operations dashboard

Privacy modes should be explicit:

Mode	What stays local	What goes to TradeOS
Public intel	local UI state and optional notes	symbol, chain, horizon, public query
Private local	portfolio, wallet context, bot rules, memory, logs	generic symbol or market queries only
Attributed feedback	private intelligence context unless included by the user	target ID, label, provenance, optional app/user attribution
Paid/private intelligence	runtime, secrets, execution keys	authenticated paid request and entitlement scope

The long-term open-source ecosystem can add bot preflight, feasibility, EA/risk checks, a light operations dashboard, and optional execution adapters, but TradeOS should remain the intelligence and validation product layer rather than a custodian, broker, managed-account service, or exchange connector.

API keys and attribution

An app key is not meant to be a private trading secret. It identifies the builder app that is reading public intelligence or sending feedback. That lets TradeOS measure demand, associate useful labels with the right integration, and keep app reputation separate from anonymous traffic.

Use a TradeOS account to manage app feedback at Builder/App Feedback. Use the Developer Keys detail page from that portal to create or rotate app keys. A key should usually represent one product or environment, such as a market briefing bot, research dashboard, validation worker, or local MCP integration.

For production builders:

• keep app keys out of public repos;
• use separate keys for development, staging, and production when possible;
• rotate keys that were pasted into public chat, logs, issues, or demos;
• submit idempotency keys with feedback writes;
• keep user identity, account verification, and automation class separate from the app key itself.

Feedback provenance

The kit should preserve feedback provenance even when the feedback comes from an agentic workflow.

{
  "target_type": "digest",
  "target_id": "digest_123",
  "label": "useful",
  "client_app": "market-briefing-bot",
  "client_version": "0.1.0",
  "feedback_source": "human",
  "automation_level": "none",
  "idempotency_key": "tradeos_public_intel_..."
}

Recommended source classes:

Feedback class	How TradeOS treats it
Human	Eligible for normal DTI credit after quality checks
Human-assisted	Useful, but normally weighted conservatively
Agent	Useful for QA, disagreement, and app reputation
Automation	Useful telemetry, not ordinary human validation by default

Agent and automation feedback still matter. They can reveal confusing answers, missing context, brittle prompts, weak target IDs, repeated failure modes, and which public objects downstream apps actually use. They should simply remain distinct from verified human review.

Venice AI pattern

The recommended agent pattern is:

TradeOS public evidence -> deterministic context pack -> Venice-compatible LLM -> user-facing answer -> attributed feedback

TradeOS supplies source-backed evidence, caveats, token identity, target IDs, and public thesis context. Venice AI or another OpenAI-compatible provider turns that evidence into readable language when the builder chooses to use an LLM.

For source-network or x402-hosted agents, TradeOS also publishes paid AntSeed/x402 Venice SKUs: tradeos-venice-raw-inference for ungrounded model output and tradeos-venice-intel-router for TradeOS evidence-backed model summaries. Use the intel router when provenance, freshness, and next-SKU routing matter.

This split keeps responsibilities clear:

• TradeOS is the evidence and feedback layer.
• The builder owns product packaging, prompts, UI, bot behavior, and inference cost.
• The LLM explains the evidence but should not invent unsupported facts or turn research into personalized trading instructions.

Free and paid boundary

The public kit is for discovery, prototyping, demos, early products, and feedback loops. It should stay useful even before a builder has paid TradeOS.

Paid TradeOS surfaces become relevant when a builder needs:

• higher-volume reads;
• deeper evidence history;
• custom universes or saved watchlists;
• alerts, webhooks, or scheduled delivery;
• private intelligence products such as dossiers, watchlists, Market Pulse depth, VPIN shock packets, private dashboard views, or premium context;
• validation datasets, regimes, outcomes, and replay;
• exports, enterprise contracts, or x402 machine access.

Data Intel Credits earned by public users are scoped to public product access: public dashboard depth, public Ask packs, or Review Lab access where enabled. They do not unlock TradeOS-hosted execution, custody, exchange connectivity, bulk exports, paid APIs, or enterprise datasets.

Safety boundaries

Builder products should keep these boundaries visible:

• no TradeOS custody or exchange credentials;
• no order placement from TradeOS infrastructure;
• direct recommendations must show evidence, assumptions, freshness, and invalidation;
• no unsupported claims outside the evidence returned by TradeOS;
• no hiding freshness, caveats, uncertainty, or invalidation notes;
• no treating automation feedback as verified human validation.

TradeOS public intelligence is research context. Builders can package it into valuable products, but the output should remain evidence-first and explicit about uncertainty.

How to contribute

Developers are encouraged to contribute apps, tools, services, examples, docs, and adapter patterns to the public kit.

Good contribution areas include:

• new bot examples for Discord, Telegram, Slack, or scheduled email;
• dashboard templates that show public evidence and feedback targets clearly;
• MCP client setup examples for agent hosts;
• typed integrations for popular worker runtimes;
• feedback UX patterns that preserve target IDs and provenance;
• evaluation scripts for comparing TradeOS public context against a builder's own signals;
• docs that show real product recipes without implying execution or financial advice.

Start from the repository README and contribution guide: agenticsrclab/tradeos-public-intel-kit.