Orbitra Prime
Trading intelligence
Access to markets and features in Orbitra Prime follows VaultID eligibility, and institutional desks map roles, approvals and subaccounts to VaultID permissions. The same credentials apply on every device and API.
VaultIDOrbitra Realm
Identity, eligibility and permission layer
Prove what is required. Reveal nothing more.
VaultID is the privacy-aware identity, eligibility and permission layer of ORBITRA ONE™. Individuals, institutions, applications and AI agents hold verifiable credentials, and markets and issuers check exactly what they need — eligibility, role, jurisdiction, mandate — through privacy-preserving credential proofs, without receiving the documents behind them.
How it moves
Four kinds of holders, one credential layer
VaultIDIndividualInstitutionApplicationAI agent
- Eligibility
- Role
- Permission
- Jurisdiction
VaultID sits at the center of the illustration, connected to four kinds of holders: individuals, institutions, applications and AI agents. Each holds credentials for eligibility, role, permission and jurisdiction. When a holder interacts with a market or an asset, the credential is disclosed selectively — a proof of what is required travels outward, while the underlying documents stay private.
The problem
Identity is copied everywhere and controlled nowhere.
Proving that you may use a financial product usually means handing over copies of documents — to a broker, then a venue, then every application that needs the same answer. Each copy is another database to secure, and each recipient learns far more than its question required.
Wallet-only systems fail in the opposite direction. They reveal almost nothing, so regulated assets and institutional workflows cannot distinguish an eligible participant from an ineligible one. Permissions, where they exist, are bolted onto individual applications and do not travel with the person, the firm or the automated agent acting for them.
VaultID separates the proof from the data. Verified facts become credentials held by their subject. Applications ask precise questions and receive verifiable answers. Permissions — for a trader, a treasury team or a Cortex agent — belong to the network rather than to each application.
Operating sequence
From verified fact to enforced permission.
The same lifecycle applies whether the holder is a person, a regulated fund, an application or an AI agent acting under delegation.
- 01
Verify
An authorized verifier checks a fact once — identity, residency, investor status, institutional role — through its own process. Source documents stay with the verifier and are never written to the ledger.
- 02
Issue
The verifier issues a verifiable credential to the subject’s VaultID. It states the fact, the issuer, the scope and the expiry, and is bound to keys the subject controls.
- 03
Hold
The holder keeps its credentials and chooses which to present, and to whom. Institutions can hold theirs under custody and approval policies of their own.
- 04
Prove
When a market or application needs an answer, the holder presents a privacy-preserving credential proof — eligible or not, in scope or not — without revealing documents or unrelated attributes.
- 05
Enforce
Identity-dependent rules — issuer transfer restrictions, jurisdiction controls, role permissions, agent mandates — are checked when a transaction executes, not only in an interface.
- 06
Revoke
Issuers can revoke credentials, grantors can withdraw delegations and every credential can expire. Status is checked at each use, so a revocation takes effect wherever the credential is relied upon.
Architecture
Components of the identity layer
VaultID keeps three things apart: who a holder is, what has been proven about it and what it is allowed to do.
- 01
Identity anchors
Each individual, institution, application and agent has a VaultID anchored to keys it controls, with key management built for Q-Switch rotation and migration.
- 02
Credential registry
Records which issuers may attest which facts, the schemas they use and the revocation status of each credential. It stores references and status, never personal documents.
- 03
Proof verification
Checks privacy-preserving credential proofs inside deterministic execution, so a contract or market module can rely on an eligibility answer without seeing the data behind it.
- 04
Permission engine
Expresses roles, approvals and limits as policy: who may trade, withdraw, approve or administer, and under which conditions. Four-eyes approvals and policy-as-code for institutions build on it.
- 05
Asset access rules
Issuers attach eligibility requirements to regulated assets. A transfer to a holder who cannot prove eligibility is rejected at execution, wherever the asset moves. See tokenization.
- 06
Agent delegation
Delegation credentials give an AI agent or application a bounded, revocable mandate on behalf of a person or institution — scope, limits and expiry — that Cortex policies reference directly.
Security and failure control
Privacy and authority, both bounded.
Identity systems fail in two directions: they leak data, or they grant authority too broadly. VaultID is designed against both.
- Data minimizationProofs answer the question asked and nothing more. Personal documents are not written to the ledger or sent to applications that only need an eligibility answer.
- Holder-controlled keysCredentials are bound to keys controlled by their holder. Institutions can apply MPC and HSM signing patterns and approval rules to the keys that represent them.
- Scoped delegationEvery delegation carries explicit scope, limits and expiry. An agent can act only inside its mandate, and the mandate can be revoked in a single action.
- Revocation at useCredential status is checked each time a credential is relied upon, so an expired or revoked credential cannot continue to grant access.
- Accountable issuersOnly registered issuers can attest registered facts, and every credential names its issuer, so a relying party always knows who vouched for what.
Across the three systems
One identity across the three systems
Orbitra L1
Settlement and compute
Credential proofs and permissions are checked inside Orbitra L1 execution, so issuer rules and jurisdiction controls hold at the protocol level. NexusWASM contracts can require a proof before acting.
Orbitra Realm
Applications and commerce
Orbitra Realm applications use VaultID through NexusSDK for sign-in, eligibility, payments and agent identity — one identity across the ecosystem instead of a new account in every application. See the AI economy.
Value
What it changes for each participant
- Traders and users
- Less data shared and fewer repeated checks. You are verified by an authorized verifier, then present proofs to supported services, subject to each service’s own requirements.
- Institutions
- Roles, approvals, delegations and eligibility expressed as enforceable policy, with evidence of every check. Compliance teams can see who was permitted to do what, and on which basis.
- Developers
- Eligibility and permissions as a network primitive. Ask a precise question — is this holder eligible for this asset in this jurisdiction? — and receive a verifiable answer without handling personal data.
Specifications
Specifications
- Holders
- Individuals, institutions, applications and AI agents
- Credential model
- Verifiable credentials naming issuer, subject, scope and expiry
- Disclosure
- Selective disclosure through privacy-preserving credential proofs
- Ledger contents
- Issuer registry, schemas and revocation status; no personal documents
- Permissions
- Roles, approvals, limits and delegations expressed as policy
- Regulated assets
- Issuer eligibility rules enforced when a transfer executes
- Agent identity
- Scoped, revocable delegation for AI agents and applications
- Key management
- Holder-controlled keys with versioned suites under Q-Switch
Access to specific products depends on jurisdiction and eligibility. VaultID enforces the rules that apply; it does not set them. See the AML, KYC and sanctions statement.
Terminology
Terminology
- Verifiable credential
- A signed statement by an issuer about a subject — for example, that an account belongs to a verified institution — that any relying party can check.
- Selective disclosure
- Presenting only the attributes or answers a relying party needs, rather than a full credential or the documents behind it.
- Credential proof
- A privacy-preserving presentation showing that a credential satisfies a requirement without exposing the credential’s underlying data.
- Delegation
- A scoped, revocable mandate that lets an application or AI agent act for a person or institution.
- Relying party
- The market, application or contract that checks a credential proof before acting.