Request Access
Company
Explore the software, infrastructure and testnet work recorded in our build.
The dated record brings together application interfaces, data services and token-rail engineering. Each entry identifies its scope and evidence status. The release plan sets out the integration and assurance work ahead.
This material may contain forward-looking statements and illustrative examples subject to risks, uncertainties, and change, including through governance decisions, regulatory developments, and technical constraints. Go-live timing is a planning reference, not a commitment.
Priority interfaces, launch journeys and evidence outputs.
Journey, gate and integration validation across the platform.
Controlled community onboarding and preparation for release.
Planned trading access, network activation and ongoing oversight.
Draft adapted from the published roadmap. Target dates updated by the owner; milestone completion remains subject to delivery review.
Company context
The engineering inventory dated 22 June 2026 records application interfaces, backend and data services, administrative tools and token-rail repositories. The figures below retain the company-reported source population and date.
The June 2026 source reports token, vesting and omnichain work in public test environments. Deployment records, network identifiers and verification artifacts are the evidence needed to inspect that work. Production activation remains subject to the applicable security, governance, configuration and release conditions.
Recorded scope
The documented estate includes participant interfaces, backend and data services, administrative controls and token-rail repositories. Current architectural naming separates seven work surfaces from five build areas. The June inventory remains a dated description of software scope; its counts need their original population and method when used in diligence.
Source: company engineering snapshot · 22 June 2026
Company-reported engineering inventory dated 22 June 2026. These values describe the source snapshot; they have not been remeasured for this page.
767 backend unit specifications · 57 end-to-end and security specifications · 25 EVM Foundry tests · 5 Solana Rust test files
Recorded test-asset inventory. Execution evidence needs its own run, scope and result.
Examples from the source inventory
The June 2026 source describes five audience-facing areas and five supporting areas. These historical inventory labels identify concrete examples of the work recorded at that time. The current architecture uses seven work surfaces and five build areas.
Company-reported interface inventory · 22 June 2026
Integration in progress in the June 2026 source
API clients in active integration in the June 2026 source
Client integration in progress in the June 2026 source
API-client wiring reported in the June 2026 source
Surface integration in progress in the June 2026 source
Testnet · company-reported · 15 June 2026
Mixed API and representative-data states in the June 2026 source
Company-reported control-plane inventory · June 2026
Backend wiring reported in the June 2026 source
Historical source inventory · June 2026. Each entry retains its reported integration context. Current availability and capability status require dated implementation and execution evidence.
Company context
The release plan connects integrated journeys, assurance, controlled participation and operation. Each stage needs evidence matched to its scope and an accountable decision before availability expands.
Historical record · June 2026
Bring the existing architecture, software inventory and testnet records into a dated evidence set. State what each artifact covers, who owns it and what further work is required.
Evidence required: Dated inventory, source references and scoped demonstrations.
Planned release work
Integrate the priority journeys with the services, permissions, gates and evidence they depend on. Review the resulting behavior end to end, including open conditions and the handling of failed or incomplete work.
Evidence required: Integrated journey tests, evidence-flow records and operability results.
Planned
Prepare a defined environment and participant scope for testing the integrated experience. Security, provider connections, data handling and operating responsibilities form part of the evidence required for that pilot.
Evidence required: Pilot scope, participant controls and security/operating records.
Planned
Introduce participants through a controlled cohort with documented eligibility, onboarding, support and monitoring arrangements. The applicable scope and authorization determine how access opens.
Evidence required: Cohort criteria, onboarding records and approval decision.
Planned · H2 2027
Bring the applicable product, security, legal, governance and operating evidence into a recorded release decision. The plan includes independent smart-contract audit, remediation, production key governance and controlled rollout. Platform go-live is planned for the second half of 2027 and remains subject to change.
Evidence required: Release decision, assurance records and verified deployment configuration.
This material may contain forward-looking statements and illustrative examples subject to risks, uncertainties, and change, including through governance decisions, regulatory developments, and technical constraints. Go-live timing is a planning reference, not a commitment.
After release · planned
Maintain the operating and change record after release. Incident handling, reporting, material updates and governed learning continue throughout the platform lifecycle.
Evidence required: Maintained reporting, change history and accountable review.
Company context
Completion is assessed against the release scope. The evidence needs to show how the participant journey, its underlying records and the operating controls work together.
Planned before public access
An independent third-party audit of the smart contracts is planned before the platform opens to public access, with remediation and re-testing of findings within the planned release path. A completed-audit statement will be accompanied by the report, its scope and the record of how findings were addressed.
Priority journeys need tested states, permissions and handoffs across the services they use.
Material actions need attributable records, reviewable decisions and an inspectable change history.
The release package needs the relevant code, access, key, resilience, incident and recovery evidence.
The release decision needs the applicable participant, provider, legal and operating conditions for its stated scope.
Questions and context
It records the company’s own assessment at the stated date and within the named scope. A technical review can examine the underlying repository, configuration, demonstration and test evidence. Each result needs its own scope and date.
Integration work, security findings and remediation, production configuration, provider readiness and jurisdictional requirements can affect the plan. Material changes need a recorded explanation and the relevant approval.
Explore the people, evidence and responsibilities behind Becoming Alpha.