Why Orbitra Exists

Modern research has three persistent problems.

Fragmentation. Information, models, and resources live in separate products. Moving between them loses context and makes a complete research trail difficult to maintain.

Opacity. An AI-generated statement can sound definitive even when the underlying source is missing, stale, or unrelated. Users need to inspect the path from observation to conclusion.

Loss of control. Agents can perform increasingly complex work. Users need clear boundaries between a generated brief, a configured resource, and a transaction they personally authorize.

Orbitra connects the pieces of a research task while making their roles legible. Agents do the work; sources provide evidence; models contribute reasoning; compute supplies resources; markets supply observable context; the wallet supplies a user-controlled onchain account. The user remains responsible for decisions and approvals.

The Orbitra Workspace

Orbitra organizes research around connected surfaces:

The workspace should allow a user to move from an agent's statement back to its source and from a proposed action back to its cost and approval. A preview is a preview; a result is a result; a wallet transaction requires its own authorization.

The Orbitra Intelligence Loop

Observe. Gather information from identified sources. Record the source, observation time, and any gaps or delays.

Synthesize. Organize observations into a useful brief. Distinguish factual inputs from model interpretation.

Verify. Compare important claims, especially numerical claims, with the underlying evidence. Mark unsupported conclusions as uncertain.

Publish. Present the brief with an inspectable record of the process that produced it.

This loop is Orbitra's product standard for research. It makes output easier to inspect; it does not guarantee that every answer is correct. Agent output does not itself authorize a trade, wallet signature, or payment.

Example: a research session

A user asks, “Why is ETH moving today?” In a connected production workflow, Orbitra would collect timestamped observations from configured sources, pass the task to the user's selected model, distinguish observed movement from possible explanations, check quoted numbers against source data, and produce a short brief with a visible activity trail. The user could inspect the evidence before deciding whether to do anything else.

The current sample research cycle demonstrates this structure with sample data. The example describes the intended connected workflow, not a claim that live feeds and paid executions are available today.

Models, Markets, and Compute

Model choice. Orbitra is the environment in which compatible models work, rather than a single proprietary model. The present workspace offers a sample experience and a configurable external chat-completions endpoint with a model identifier and user-provided API key. Requests to a configured provider are sent from the user's browser. Provider availability, charges, and handling of prompts remain subject to that provider's terms. A model response is generated analysis, not independently verified source data.

Market context. Markets is intended to become an observable context layer for research agents. Each live reading must have a source, a time, and an honest unavailable state when data is missing. Until a reliable live feed is connected, figures shown in the workspace are labeled as sample data.

Compute choice. Small questions and sustained workloads need different resources. Orbitra presently allows users to inspect light, balanced, and power-oriented profiles and preview a session length. This is configuration, not allocation. Actual provisioning requires a provider connection, availability, stated pricing, confirmation, and a visible session state.

These layers compose into a user-directed workflow: choose a task and model, inspect the data it uses, understand the resources it requires, and review the result.

The Orbitra Economy

The Orbitra token is intended to be a common access and settlement asset for eligible intelligence services in the workspace. A shared asset can give different services a consistent payment flow as the product expands. The token does not, by itself, produce an agent result, reserve compute, or unlock an unfinished service.

Eligible services may eventually include agent executions, deeper research jobs, model inference, compute sessions, specialized data queries, and third-party agent services. Each offering must identify what is delivered, its provider, its price or pricing rule, and the moment the user authorizes payment. Paid functionality should be described as available only after it is implemented and tested.

User authorizes a priced task → Orbitra routes the service request → the service delivers a result or session → payment settles under published terms.

Orbitra does not announce a credit conversion, a burn rule, staking rewards, or holder distributions in this paper. Such mechanisms would need their own specification before becoming product features. Holding the token confers no ownership of Orbitra Labs, entitlement to revenue, guaranteed return, or guaranteed future service access.

Launch Through Pons v2

The Orbitra token will launch through pons v2 on Robinhood Chain. Under the documented v2 lifecycle, a launch configuration fixes the token supply and curve terms. The entire initial supply is minted to the bonding curve, with a portion reserved by the mechanism for pool liquidity. Buyers initially trade against the curve. After the curve sells out, a Uniswap v4 pool is created and its liquidity is locked permanently. The creator is not allocated a presale bag by the launch mechanism. A creator can, however, buy tokens, so any creator purchases and resulting holdings should be disclosed. Pons v2 documentation ↗

Pons v2 is distinct from pons v1. The earlier description of an immediate WETH pool, a universal one-billion-token supply, and a blanket 70/30 fee split was based on v1 and does not establish Orbitra's v2 launch terms. The chosen v2 configuration, pair asset, fee policy, and transaction will establish those terms. Pons v1 documentation ↗ · Pons v2 documentation ↗

Pons v2 permits an optional creator tax fixed at launch and an optional buyback funded from the creator's fee share. Under its documented design, tokens acquired through that buyback vest over time; they are not burned. This paper does not commit Orbitra to enabling either option. The actual fee distribution must be read from the launch's settings rather than assumed from a different pons version. Pons v2 documentation ↗

Creator fees, if earned, are a source of project funds, not a distribution right for token holders. Orbitra Labs may use funds it receives for model access, infrastructure, compute, data, development, and operations, subject to a published fee policy. No specific percentage or spending commitment is asserted until that policy and its recipient wallet are published.

Before trading begins, Orbitra Labs should publish one authoritative token page with the final supply, pair asset, configuration, contract address, creator payout wallet, trading fees, optional tax, buyback setting, and transaction links. Token names and symbols can be imitated; users should verify the contract address.

Wallets and User Control

The current wallet surface reads a connected address, network, and native balance where a supported wallet is available. Reading account context does not require a token approval, payment, or transfer. Connecting a wallet does not transfer custody to Orbitra.

Any future paid task must provide a separate confirmation showing the network, destination, asset, amount, purpose, and expected service before the user signs. A research brief cannot silently turn into a transaction. Wallet state, payment state, and service delivery should each have their own visible record.

Verifiable by Design

Orbitra joins several systems whose outputs have different meanings:

• Source observations may be delayed, incomplete, or incorrect; show provenance and timing.
• Model responses may contain errors; distinguish them from checked facts.
• External providers may receive prompts and apply separate pricing and data terms.
• Compute providers must confirm capacity and actual allocation before a session is shown as active.
• Wallets and contracts operate under explicit user approvals and published addresses.
• Launch mechanics must be checked against Orbitra's actual v2 configuration and onchain transaction.

Orbitra should reveal what a workflow read, generated, verified, paid for, and delivered. Where a step did not happen, the interface should say so.

Product Status

This status reflects the supplied Orbitra whitepaper at this revision, not a live deployment audit. The token launch, service delivery, and connected integrations must be verified through the product and published onchain records as they become available.