Trust & Evidence
SecurityControls
Security is engineered across participant access, application requests, token transfers and cross-chain messaging. The implementation includes authentication controls, permission checks, transfer restrictions and route limits. Production key governance, operating procedures and independent assurance each have defined verification requirements, with the status of those requirements kept visible for institutional and technical review.
Inspect the controls, their implementation scope and the evidence needed for release.
On this page
Independent review status
IndependentAssurance
Third-party smart-contract audit
Planned before public access
An independent third-party audit of Becoming Alpha’s smart contracts is planned before the platform opens to public access. The audit’s scope, findings and remediation record will form part of the evidence considered in the release decision.
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.
Explore Progress & RoadmapSecurityControls
Review the mechanisms across application access, token activity and operational authority. Each layer identifies the implementation work and the configuration or verification needed to assess it.
Identity Controls
The authentication source implements authenticator-app, email and backup-code verification, wallet-signature checks with challenge validation, and session handling. Signed access-token (JWT) validation includes user-token revocation checks; external identity configuration supports OIDC. Release review establishes which methods are enabled, how recovery works and how access behaves with invalid, expired or replayed credentials.
- Implementation source
- Authentication and revocation code
- Verify
- Enabled methods, recovery and adverse cases
Application Boundaries
API security code combines signed-token authentication, role and action-permission checks, rate limiting and brute-force controls. Request-signing middleware checks signatures, timestamps and nonces on applicable requests. Security and authentication events are logged. Verification must cover the actual route permissions, participant boundaries and enabled middleware, including attempts to perform actions or read records outside the permitted scope.
- Implementation source
- API guards and request controls
- Verify
- Route permissions and runtime configuration
Token Controls
The Ethereum-compatible (EVM) token code provides role-controlled pausing, optional transfer-restriction modules and inbound and outbound rate controls for each cross-chain route. Separate role definitions govern sensitive settings. Tests are defined for pause behavior, access roles, restrictions and rate limits. Deployment review must establish the assigned authorities, enabled modules, configured limits and execution results for the release candidate.
- Implementation source
- EVM contract controls and test suites
- Verify
- Authority, enabled limits and current results
Omnichain Controls
LayerZero OFT configuration defines connected contract peers, verifier networks (DVNs), confirmation requirements and execution options. Route review must establish the settings at both ends of each connection, the actual verification threshold and the enabled transfer limits. Local configuration checks cover selected invariants and address consistency. Deployed configuration and route-specific testing provide the evidence required for operational acceptance.
- Configuration source
- Peer, verifier and route settings
- Verify
- Deployed settings and cross-chain execution
Privileged Authority
Production privileged actions are planned around multi-signature approval, applicable timelocks and separated responsibilities. The handoff design covers contract roles, ownership, signing authority, recovery and emergency powers. Deployment verification must establish the actual signer configuration, approval threshold, enabled delay and authority assignments, then demonstrate the approval and recovery paths for the relevant environment.
- Planned production controls
- Multi-signature approval, timelocks and role separation
- Verify
- Signer configuration, authority assignments and approval-path tests
Operational Response
Authentication and security events feed logging and alert-handling code, including failed logins, token reuse and rate-limit events. Alert delivery depends on enabled configuration and selected channels. Operational acceptance requires confirmed response ownership, escalation paths, recovery procedures and rehearsals, with incident findings linked to treatment and retesting. The source establishes implementation work; environment-specific records establish operating readiness.
- Implementation and planned operations
- Logging and alert integrations; response preparation
- Verify
- Delivery, escalation and recovery evidence
Read the basis
AssuranceSequence
The security review connects an identified exposure to implementation, adversarial testing and treatment of findings. Each record needs the relevant code version, environment, scope and responsible owner.
DefineControls
Map the assets, trust boundaries and privileged actions. Connect each exposure to a control, its implementation source and the configuration it depends on. Identity, participant permissions, contract authority and cross-chain routes each require explicit assumptions and acceptance conditions.
ExerciseFailures
Use the security and contract test suites to exercise invalid credentials, replay attempts, permission failures, pausing and route limits. Record the tested version, enabled configuration, results and coverage limits. Existing test code provides a basis for current execution and review.
ResolveFindings
Assign treatment and responsibility to findings, retain open issues, and link changes to retest evidence. Independent review has its own scope and reporting record. Relevant unresolved matters remain visible in the release decision, alongside the approved production authority and response arrangements.
Planned security program
ResearcherReview
A managed bug-bounty program is planned to bring independent security researchers into the assurance process.
The proposed framework covers eligible assets, reporting scope, severity assessment, triage, remediation and coordinated disclosure. Program terms, reward arrangements and operating ownership require confirmation before participation opens.
Program statusPlanned
Intended sequence
Report
Researchers submit findings through a published intake route, within a defined scope.
Triage
Each report is validated, checked against known issues and assessed for severity.
Remediate
Confirmed issues enter incident handling with a responsible owner.
Retest
The fix is exercised against the original finding before the record closes.
Disclose
Disclosure is coordinated with the researcher after remediation.
This section describes a planned program. Intake, program terms, reward arrangements and an opening date have not been confirmed.
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.
Responsibility and context
ReleaseResponsibility
A release decision requires evidence relevant to the actual code, configuration and environment concerned. Security requirements and historical test reports each have a defined scope. Current execution, findings, required independent review and acceptance records need to be examined together, with open matters and responsibility retained in that decision context.
Questions and context
FurtherDetail
Has an independent smart-contract audit been completed?
Not yet. An independent third-party audit of the smart contracts is planned before the platform opens to public access. Its scope, findings and remediation evidence will be available for examination within the relevant release process.
How should I interpret a test result?
Read it with the tested source version, environment, conditions and coverage. Review the findings, limitations and any retest record relevant to the question you are assessing.
Can a security specialist discuss contributing?
Use Request Access to describe your discipline and proposed scope. Any engagement needs agreed responsibilities, permissions, deliverables and review conditions.
How will security researchers contribute?
A managed bug-bounty program is planned, with defined scope, severity assessment and reporting procedures. The published program terms will establish eligible testing, reward arrangements and coordinated disclosure when participation opens. The current materials describe the plan; the operational program requires its own evidence.
ContinueExploring
Follow the sources and participation route relevant to your review.