Enterprise Technical Documentation
SE BASE ExplorerBlocks and transactions ↗Technical ReferenceProtocol Architecture · Asset Standards · Application Interfaces
Protocol Architecture
Consensus、決定論的実行、資産、公開Interface、相互接続、監視統制を一つのProtocol Architectureとして構成します。
Eighteen native functions share one deterministic protocol architecture.
Certified finalityDeterministic executionObservable public interfaces
Integrated protocol architecture
Function 01–18 are specified as one integrated native system; implementation and activation are separately gated.
The architecture preserves the separate roles of consensus, execution, assets, interfaces, interoperability and monitoring while binding them to a common network identity and evidence model.
各機能の役割を分離したまま、共通のNetwork Identity、Finality、Evidence Modelによって一体化しています。
Native functions 01–18
The eighteen functions form one integrated native system. These are protocol specifications; availability in a running network is determined separately for that environment.
| ID | Function | Specified operation | Technical boundary |
|---|---|---|---|
| 01 | Digital token & NFT issuance | Issue and manage third-party digital tokens and NFTs through versioned native templates. | Versioned native templates and deterministic state transitions define the execution surface. |
| 02 | Flexible supply design | Define fixed, capped or scheduled-release supply policies deterministically through canonical integer rules before issuance. | Authorisation, recorded history and supply invariants govern every later change. |
| 03 | Pre-determined addresses | Derive reproducible asset addresses and identifiers from canonical inputs before issuance. | The derivation is independent of runtime timing, randomness and external responses. |
| 04 | Public asset verification | Make supply, issuer, metadata and state inspectable from finalised public information. | Published values are anchored to finalised state and its verification path. |
| 05 | Signing-key rotation | Renew or revoke signing keys while preserving address, authority, assets and history. | Key epoch and activation height bind each authorised transition to finalised state. |
| 06 | Fee sponsorship | Allow an authorised sponsor to settle a user’s network fee. | Sender and sponsor authorise the same canonical payload while sender value and sponsor fee remain separately accounted for with integer rules. |
| 07 | Transaction validity period | Give every signed transaction a defined validity range. | Validity bounds, nonce, chain domain and clock bounds work together against replay. |
| 08 | Constrained execution | Execute versioned native templates through a closed set of deterministic host functions. | The fail-closed execution boundary admits only versioned templates, closed host functions and explicit metering; arbitrary bytecode, dynamic external calls, floating point and unspecified system I/O remain outside the execution surface. |
| 09 | Non-custodial submission | Submit a canonical transaction after the user has signed it with their own key. | The public submission path carries signed raw transactions while keys remain with their holder. |
| 10 | Fee model | Calculate base fee, priority fee and resource metering with deterministic integer rules. | Deterministic settlement binds workload-aware accounting and supply invariants to state without validator-supplied arbitrary inputs, floating point or minting outside the fixed supply. |
| 11 | Supply-integrity verification | Recalculate live, escrowed and burned quantities for every asset. | The resulting accounting root is committed with the State Root. |
| 12 | Finality protection | Prove finality with signed power strictly greater than two thirds of the validator set. | The rule is signed_power × 3 > total_power × 2; with three equal validators, finality requires 3/3. |
| 13 | Validator-set expansion | Expand or change the validator set at an authorised activation height. | The transition requires strict-quorum certificates from both the previous and next validator sets. |
| 14 | Ledger persistence | Persist blocks, receipts, state and finality certificates atomically. | Recovery begins from a root-verified snapshot of finalised state. |
| 15 | Block-header version transition | Move between block-header versions at a defined activation height. | Compatibility rules and version evidence remain explicit across the validator set. |
| 16 | Deterministic high-speed processing | Identify non-conflicting transactions through a conflict graph, execute them as parallel candidates and revalidate read and write sets in canonical order. | Atomic commit proceeds only when State Root, Receipt Root, event order and Fee Root match canonical serial execution; serial fallback preserves determinism, and performance is stated only with accepted Benchmark Evidence. |
| 17 | Post-quantum cryptography | Combine classical and approved PQC signatures through a versioned algorithm registry, with key epoch and chain-domain binding. | Candidate algorithms remain disabled until a signed activation decision, provider tests and rotation and revocation evidence are accepted. |
| 18 | Chain issuance orchestration | Generate an independent-chain or subchain configuration with its own Chain ID, clean Genesis, validator set, ledger, policy and artifact digest deterministically from a canonical request. | The versioned offline package shares no state, keys, assets or consensus with the parent network; deployment, publication, asset movement and Bridge connection proceed through separate authorisation. |
Consensus and execution requirements
| Area | Requirement |
|---|---|
| Finality | signed_power * 3 > total_power * 2. Validate voting power and the ratified validator set for the certificate height. |
| Deterministic execution | Identical canonical input must produce identical state. Time, randomness, external I/O and provider responses must not determine consensus state transitions. |
| Native runtime | Versioned native templates and explicit host functions define execution. Generic EVM execution and arbitrary bytecode are not the Mainnet state-transition model. |
| Network separation | Mainnet and Testnet 2 use separate Genesis, validator sets, state, keys, namespaces and activation records. |
| Failure handling | Reject identity mismatch, invalid signatures, replay, unratified validator sets and invalid digests before state acceptance. |
| Message admission | Apply finite message-count and byte limits before retention. Unverified-message capacity and canonical synchronization budgets remain independent. |
Protocol domains
| Protocol domain | Specified or observed property | Deterministic effect | Evidence surface |
|---|---|---|---|
| Network identity | Chain ID and canonical genesis binding | Environment identity remains explicit. | RPC and Explorer evidence |
| Finality | Certificate and voting-power threshold | Advancing state remains distinct from accepted state. | Finality certificate and signed power |
| Validator set | Epoch and validator-set hash binding | Unknown, duplicate and invalid signatures are rejected. | Certificate verification record |
| State | Block hash, certificate and state-root linkage | Accepted state is cryptographically connected. | Explorer JSON readback |
| Public interface | Approved read-only method boundary | Administrative methods remain outside public access. | RPC method surface |
| Recovery | Chain-identity-bound checkpoint and snapshot | Recovery state remains bound to the canonical network. | Checkpoint and parity record |