Public Verification Record - 13 September 2026

RANNTA X-Chain Hybrid Security Evidence

This record documents implementation-enforced behavior in the RANNTA X-Chain native HybridRequired authorization path. It focuses on what the authorization logic accepts, rejects and tracks when classical secp256k1/ECDSA evidence and ML-DSA-65 post-quantum evidence are bound to the same protected operation.

Scope and independence notice: this is a RANNTA-published implementation evidence record. It is not a third-party audit, certification or independent security assessment. It is intended to expose the authorization rules and failure modes that can be checked against the current X-Chain implementation. A separate third-party security review remains part of the expansion program.
NetworkRANNTA X-Chain - Chain ID 13113 / 0x3339
Authorization policyHybridRequired - Fail-Closed
Cryptographic factorssecp256k1/ECDSA + ML-DSA-65
Implementation snapshot1e1d5f324af6e6766d47e6dc5e22fc20863b4554
Post-quantum standardML-DSA-65 - NIST FIPS 204
Public runtime surfaceRPC and explorer live

1. Native Hybrid Authorization Evidence Matrix

The table below records the enforcement behavior represented by the native authorization implementation. "Implemented" or "Enforced" means the behavior is present in the authorization code path; it does not mean an independent auditor has certified it.

Security caseExpected behaviorImplementation signalStatus
Valid hybrid authorization
Valid ECDSA and valid ML-DSA-65 evidence under the correct context.
Authorize the protected request for execution processing.status=authorized_pending_executionIMPLEMENTED
Classical-only authorization on a HybridRequired accountReject instead of silently falling back to legacy authorization.hybrid_requiredENFORCED
Invalid ML-DSA-65 signatureReject the authorization.invalid_ml_dsa_signatureENFORCED
Invalid secp256k1/ECDSA signatureReject the authorization.invalid_ecdsa_signatureENFORCED
Duplicate transaction / replayReject a transaction hash already recorded as executed.duplicate_transaction_hashENFORCED
Reused key-lifecycle operation identityReject reuse of an operation identity already consumed by registration or rotation.duplicate_transaction_hashENFORCED
Key version rollbackReject registration or rotation that does not move to an allowed higher key version.key_version_rollbackENFORCED
Wrong PQ key versionReject authorization bound to a different registered PQ key version.wrong_pq_key_versionENFORCED
Wrong chain identityReject evidence that is not bound to RANNTA X-Chain Chain ID 13113.wrong_chain_idENFORCED
Expired or premature validity windowReject authorization outside its configured block-validity window.expired_transaction / premature_transactionENFORCED
ML-DSA backend unavailableFail closed rather than treating missing PQ verification as success.ml_dsa_backend_unavailableENFORCED

2. Canonical Context and Replay Binding

Hybrid authorization is not treated as two unrelated signatures. The native path binds authorization evidence to a defined RANNTA X-Chain security context. The implementation includes chain identity, transaction/account fields, validity bounds, PQ key version, authorization policy version and operation identity in the protected authorization flow.

Domain separation

The native hybrid domain is versioned as RANNTA-XCHAIN-HYBRID-NATIVE-V1.

Transaction replay state

Executed transaction hashes are tracked and duplicate insertion is rejected.

Operation replay state

Used operation IDs are tracked for protected key-lifecycle operations.

3. Key Registration, Hybrid Activation and Rotation

The native authorization registry records the account authorization mode, ML-DSA-65 public key, public-key hash, key version, registration block, activation block, policy version and rotation counter.

Authenticated registration

Key registration binds classical account authority and ML-DSA-65 proof to the canonical key operation.

HybridRequired activation

Once the account is placed in HybridRequired mode, legacy-only authorization is rejected on the protected native path.

Versioned rotation

Rotation requires an incremented key version; rollback or non-incrementing rotation is rejected.

4. Wire-Level Failure Signals

The implementation exposes deterministic error codes for security-relevant rejection paths. Selected examples:

hybrid_required
hybrid_required_irreversible
invalid_ecdsa_signature
invalid_ml_dsa_signature
ml_dsa_backend_unavailable
duplicate_transaction_hash
key_version_rollback
wrong_pq_key_version
wrong_chain_id
expired_transaction
premature_transaction
invalid_block_authorization_evidence

5. Consensus Scope

RANNTA consensus engineering implements HybridRequired authorization surfaces across validator-sensitive proposal, vote and finality paths. Broader distributed validator deployment is the topology-scale expansion of this implemented authorization model.

The HybridRequired consensus authorization model is implemented independently of validator-count growth. Network expansion broadens distributed participation without redefining the protected authorization path.

6. Public Reproduction Status

PUBLISHED

Implementation behavior and wire-level enforcement signals are documented in this record.

LIVE

RANNTA X-Chain public RPC and explorer are available for network-level inspection.

PENDING PUBLICATION

A one-click public reproduction harness with timestamped command/output artifacts, build identity and block references is being tracked as a separate verification artifact.

Evidence boundary: this record separates implementation-enforced behavior from independently reproducible runtime artifacts. A public reproduction harness can extend this record with timestamped outputs, build identity and block references without changing the implemented HybridRequired security model documented here.

7. Verification Links