Certified finality, validator epoch safety and synchronization controls
Institutional Technical Reference
Live Public ExplorerFinalized readback ↗Technical ReferenceInstitutional Technical Reference · 2026 Edition
Social Ecosystem Chain
プロトコル・アーキテクチャ／資産標準／相互運用／制度的ガバナンス
One controlled reference for protocol architecture, digital assets, interoperability, implementation and institutional accountability.
プロトコル、デジタル資産、相互運用、実装、制度的責任を一つの体系として整理した公式技術書。
Document · JSEC-TR-2026Revision · 2026.08.02 / R36Core source · 6de0979b9725Authority · JAIOS Institutional GovernanceEvidence · Separated & ReadableNetwork · Governed Read-only Operations
Release Status / 公開状態
Core implementation and live runtime are reported separately.
実装済みのChain Coreと、実環境での受入が必要なRuntimeを分離して表示します。
Runtime acceptance verified by current Explorer evidence
Three-validator finality and advancing head are verified
Read-only evidence access is available; transaction submission remains disabled
Explorer and RPC evidence remain read-only and independently inspectable
A separate institutional release decision is required
All interoperability routes remain paused and evidence-gated
No bridge-mediated or production asset movement is represented
Abstract / 文書要旨
Read the system by architecture, implementation and evidence.
アーキテクチャ、実装、証跡の順に、技術判断へ必要な情報へ到達する。
- Document class
- Institutional Technical Reference
- Protocol authority
- JAIOS Institutional Governance
- Network state
- Governed Read-only Operations
- Publication state
- Documentation Live · Network Operational Evidence Available
IV
Adoption & Implementation
Applied architectures, implementation and adoption.
適用構造・実装・導入工程
Protocol Scope
Completed-state protocol architecture.
完成時のプロトコル・アーキテクチャ。
JUNCA Social Ecosystem Chain provides a trust, participation and value-circulation layer for institutional applications, digital assets and interoperable services. The architecture separates protocol governance, network operation, partner-owned asset administration and independent evidence.
JUNCA Social Ecosystem Chainは、制度的アプリケーション、デジタル資産、相互運用サービスを支える、 アクセス・アイデンティティ・価値循環の信頼基盤です。プロトコル統制、ネットワーク運用、 パートナー資産管理、独立証跡を明確に分離します。
Consensus, execution, state, network identity and upgrade boundaries.
RPC, WebSocket, Explorer, Faucet, SDK and partner integration surfaces.
Release decisions, runtime acceptance, custody, monitoring and rollback records.
Define purpose
Review architecture
Build & test
Runtime acceptance
Operate & evidence
Mainnet release is a separate institutional decision.
Implemented / CI Verified
Certified Finality and Validator Epoch Safety
認証済みFinalityとValidator Epoch保護
JUNCA Social Ecosystem Chain verifies synchronized block ranges against certified finality evidence. The current source also validates trusted checkpoint anchors, canonical persisted state, authenticated peer frames and live runtime evidence bundles before acceptance. Each proof is bound to the chain identity, block height, round, block hash and active validator-set hash. Duplicate, unknown or invalid validator signatures are rejected, and strict greater-than-two-thirds voting power is required before a finality certificate is accepted.
JUNCA Social Ecosystem Chainは、同期対象のBlock Rangeを認証済みFinality証跡と照合します。現行Sourceは、Trusted Checkpoint Anchor、Canonical Persisted State、Authenticated Peer Frame、Live Runtime Evidence Bundleも受入前に検証します。各ProofはChain Identity、Block Height、Round、Block Hash、Active Validator Set Hashへ拘束されます。重複Validator、未知Validator、不正署名を拒否し、Finality Certificateの成立には厳格な3分の2超のVoting Powerを必要とします。
Validator Set変更をBlock Heightへ拘束
有効Validator Set Hashを検証
旧EpochのValidator Proofを拒否
Chain IDとGenesisをProofへ拘束
重複・未知ValidatorをFail-Closedで拒否
開発環境CIの検証証跡を確認済み
Capability Register
Functions and completion criteria.
機能体系と完成条件。
| Capability | Use | Control surface | Specification role | Completion criterion |
|---|---|---|---|---|
| Authenticated validator sync | Canonical peer catch-up | Consensus boundary | Implemented / CI verified | Chain ID, genesis, session and schema binding with peer quarantine |
| Certified finality | Synchronized block-range verification | Consensus boundary | Implemented / CI verified | Epoch-bound validator set, strict >2/3 voting power and certificate validation |
| Snapshot catch-up | State synchronization | Recovery boundary | Implemented / CI verified | Checkpoint digest, chunk integrity and certified-finality binding |
| Smart contract execution | DApp and asset logic | Execution layer | Core specification | Client compatibility and deterministic execution acceptance |
| Fungible token issuance | Utility, access, points | Asset control | Asset specification | Approved standard, supply policy and separated administration |
| NFT issuance | Membership, certificate, provenance | Rights and metadata | Asset specification | Approved standard, metadata integrity and rights control |
| Wallet integration | Signing and asset access | Application interface | Integration specification | Verified network binding, signing policy and interface-safe errors |
| Public RPC / WebSocket | Network connection | Network interface | Network service | TLS, method allow-list, rate limits, monitoring and parity |
| Explorer verification | Transaction and contract evidence | Evidence interface | Evidence service | Block, transaction and contract parity with canonical RPC |
| Faucet | Test asset distribution | Testnet control | Testnet service | Rate limits, abuse protection and auditable issuance |
| Ethereum / ERC interoperability | ERC-20 and ERC-721 cross-network route | Custody boundary | Controlled route | Verified contracts, custody, relayer quorum and independent review |
| BSC interoperability | ERC-20/BEP-20 and ERC-721 route control | Custody boundary | Controlled route | Verified contracts, custody, relayer quorum and independent review |
| TRON interoperability | ERC-20/TRC-20 and ERC-721/TRC-721 route control | Custody boundary | Controlled route | TVM verification, custody, relayer quorum and independent review |
| Scalability profile | Capacity planning | Performance boundary | Performance specification | Published load, chaos, recovery and state-growth evidence |
Operational availability is accepted only when the corresponding completion criterion is supported by current evidence in the canonical release record.
Fungible Asset Architecture
Supply, authority and treasury control.
供給・権限・トレジャリー統制。
Purpose & economics
Define function, operating domains, supply logic, distribution, vesting and off-chain obligations before selecting a contract standard.
用途、供給、配布、Vesting、会計・法務上の責任を先に確定します。
Authority & custody
Separate owner, mint, burn, pause, treasury and upgrade roles. Prefer multisig or institutional custody where the risk profile requires it.
Owner、Mint、Burn、Pause、Treasury、Upgradeの権限を分離します。
Compatibility gate
Each approved token standard, upgrade pattern and development toolchain passes client-level compatibility, negative testing and deployment verification before release.
承認対象のトークン規格、アップグレード方式、開発ツールは、公開前にクライアント互換性、Negative Test、配置検証を完了します。
Purpose & classification
Supply & authority
Contract & tests
Testnet evidence
Release & monitoring
Economic treatment and legal classification are governed separately from protocol testing and require jurisdiction-specific review.
Fixed supply
No post-release minting; migration planning becomes central.
Mintable
Requires controlled mint authority, limits and observable events.
Burnable
Requires clear holder/admin rights and supply reconciliation.
Upgradeable
Adds administrator and migration risk; must be explicitly governed.
Non-Fungible & Credential Architecture
Identity, provenance and metadata permanence.
識別性・来歴・メタデータ永続性。
Asset models
The asset layer supports single assets, collections and governed semi-fungible patterns for membership, certificates, access passes, authenticity records and licensed brand or IP assets.
Metadata discipline
Record schema, storage, integrity hash, update authority, retention, licensing and migration. Personal information should not be placed on-chain or in public metadata.
Distributed storageIntegrity and persistence planning; availability still requires operational stewardship.
Managed storageControlled service levels and access; introduces provider and continuity dependencies.
Hybrid recordOn-chain digest plus governed off-chain asset; requires recovery and migration evidence.
Rights & schema
Asset storage
Integrity digest
Mint & transfer policy
Preservation & migration
Token URI, royalties and transfer restrictions are governed, tested and recorded as part of asset acceptance.
Interoperability Control Plane
Ethereum / ERC, BSC and TRON route architecture.
Ethereum／ERC・BSC・TRON相互運用経路。
Interoperability uses deterministic, fail-closed route validation, a bidirectional message-state engine and destination-chain execution contracts. Each route binds explicit network identity, custody, relayer quorum, finality, replay protection, limits and emergency controls.
相互運用は、決定論的なFail-Closed経路検証、双方向メッセージ状態機械、 対象チェーン実行コントラクトで構成します。各経路は、ネットワーク識別、Custody、 Relayer Quorum、Finality、Replay Protection、利用上限、緊急停止を明示的に結合します。
Source and destination networks, contracts, assets and message domains are explicit.
Finality, quorum, replay protection, limits and paused-by-default release.
Custody binding, deployed-code verification, security review and live operational evidence.
| Route | Asset mapping | Network identity | Bridge mode | Activation rule |
|---|---|---|---|---|
| JUNCA ↔ Ethereum | ERC-20 / ERC-721 | Explicit chain and contract binding | lock / mint / burn / release | Evidence gated |
| JUNCA ↔ BSC | ERC-20 ↔ BEP-20 | Explicit BSC network binding | lock / mint / burn / release | Evidence gated |
| JUNCA ↔ BSC | ERC-721 ↔ compatible ERC-721 | Explicit BSC network binding | lock / mint / burn / release | Evidence gated |
| JUNCA ↔ TRON | ERC-20 ↔ TRC-20 | Explicit TRON network binding | lock / mint / burn / release | Evidence gated |
| JUNCA ↔ TRON | ERC-721 ↔ TRC-721 | Explicit TRON network binding | lock / mint / burn / release | Evidence gated |
OBSERVED
FINALITY_VERIFICATION
ATTESTED
EXECUTION_READY
EXECUTED
Execution readiness requires finality, verified relayer quorum, an unpaused approved route and limit checks.
Paused by default
A new route cannot execute until institutional release approval.
Relayer quorum
At least three distinct relayers; threshold is two or more verified signatures.
Finality
Execution readiness requires the configured confirmation depth.
Replay protection
Message, source transaction and source nonce are independently rejected on reuse.
Custody & roles
Institutional multisig, separate guardian and KMS/HSM-backed relayer keys are release prerequisites.
Limits & incident control
Per-transaction and daily limits, emergency pause and an approved incident runbook.
Compatibility boundary / 互換性境界
BSC Testnet is identified by EVM Chain ID 97. TRON Shasta is identified astron-shasta; no fictitious EVM Chain ID is assigned. Solidity compilation does not prove TRON TVM compatibility. Target-chain compilation, deployment, source verification and independent security review are mandatory before route activation.
BSC TestnetはChain ID 97、TRON Shastaはnetwork identifier「tron-shasta」で識別します。 Solidityのコンパイル成功だけではTRON TVM互換性を証明しません。経路有効化前に対象チェーンでの検証を必須とします。
Applied Architectures
Asset, credential and service patterns.
資産・証明・サービスの適用構造。
| Use case | On-chain | Off-chain | Primary control | Architecture |
|---|---|---|---|---|
| Enterprise utility token | Balances, transfer events | Terms, account records | Supply and treasury | Reference pattern |
| Loyalty / points | Optional asset record | Customer and settlement data | Privacy and reconciliation | Reference pattern |
| Membership credential | Credential reference | Member profile | Revocation and privacy | Reference pattern |
| Brand / IP NFT | Ownership and provenance | Media and licence | Rights and metadata | Reference pattern |
| Authenticity certificate | Digest and issuer | Product dossier | Issuer custody | Reference pattern |
| Ticket / access pass | Access asset state | Identity and event ops | Transfer and expiry | Reference pattern |
| Regional ecosystem token | Asset and settlement events | Local operating rules | Governance and compliance | Reference pattern |
| Digital certificate | Digest and status | Evidence file | Issuer and revocation | Reference pattern |
| Community services | Service receipt | Protected records and moderation | Data minimization | Reference pattern |
| DApp / marketplace | Contract events | Search, content, support | Platform and contract admin | Reference pattern |
Enterprise record
Data classification
Minimal on-chain state
Governed off-chain evidence
Audit readback
Implementation Reference
Network binding, contract toolchain and verification.
ネットワーク接続・コントラクト実装・検証体系。
Verification in Progress
Public Testnet Network Configuration
実値はAWS Runtime Acceptance完了後、承認済みNetwork Registryから公開します。未確定値は推測しません。
| Field / 項目 | Published value / 公開値 | Acceptance boundary / 受入条件 |
|---|---|---|
| Network Name | JUNCA Social Ecosystem Chain Public Testnet | Controlled public-testnet designation |
| Chain ID | 20260723 | Verified operational readback; wallet registration remains separately governed |
| Public RPC URL | Read-only policy | Transaction submission is disabled; use the Operational API for published status |
| WebSocket URL | Not published in this reference | No endpoint is inferred from implementation state |
| Explorer URL | explorer.jaios-governance.org | Finalized, read-only public evidence surface |
| Currency Symbol | Not asserted | No test asset symbol is published before registry approval |
| Faucet URL | Not asserted | No faucet endpoint is published without auditable issuance controls |
| Genesis Hash | Not published in this reference | No hash is inferred; it must match the deployed canonical genesis |
| Finality Policy | Certified finality · 3 / 3 observed | Verified against the current read-only Explorer snapshot |
- 01Prerequisites
Node.js 22+, an approved wallet, test-only account, source control and a secrets-safe environment.
- 02Network configuration
Integrations consume the published network registry for Chain ID, RPC, WebSocket, Explorer, Faucet and currency metadata. Configuration is never copied from unverified examples.
- 03Contract toolchain
Approved compiler targets, dependencies and asset standards are pinned to the canonical compatibility matrix and verified at deployment.
- 04Release evidence
Compile, unit test, negative test, security review, testnet deployment, Explorer verification and monitoring evidence form one release packet.
Testable configuration guard
// network-readiness.mjs
const network = {
name: "JUNCA Social Ecosystem Chain Public Testnet",
chainId: Number(process.env.JUNCA_CHAIN_ID),
rpcUrl: process.env.JUNCA_TESTNET_RPC_URL,
explorerUrl: process.env.JUNCA_EXPLORER_URL,
notice: "Public Testnet / Protocol Validation Environment"
};
if (!network.chainId || !network.rpcUrl || !network.explorerUrl) {
console.info("Registry verification in progress");
}
console.log(JSON.stringify({
...network,
rpcUrl: "[verified / redacted]"
}, null, 2));Configuration examples are published only from an accepted network registry and redact secrets by design.
Wallet
Partner DApp
Public RPC boundary
Validator quorum
Explorer parity
Public administrative, debug, mining, personal and txpool methods are intentionally not exposed.
Getting Started
前提環境、公開状態、テスト専用アカウントを確認します。
Guide AvailableNetwork Configuration
承認済みNetwork Registryのみを使用し、未確定値を推測しません。
Evidence-bound Read-only AccessWallet Setup
Chain ID、RPC、Currency Symbolの公開後にWalletへ登録します。
Evidence-bound Read-only AccessRPC Reference
公開許可Methodと禁止Methodを分離し、管理系RPCを公開しません。
Evidence-bound Read-only AccessSmart Contract Deployment
Compiler、Dependency、Source Commit、Deployment Evidenceを固定します。
Evidence-bound Read-only AccessToken Standard
Supply、Mint、Burn、Pause、Treasury権限を分離して検証します。
Evidence-bound Read-only AccessNFT Standard
Metadata、権利、Storage、Integrity Digest、Migrationを定義します。
Evidence-bound Read-only AccessSDK and Samples
Runtime Binding完了後に正本Repositoryから提供します。
Evidence-bound Read-only AccessFaucet
Test Asset Separation、Rate Limit、Abuse Controlを前提に公開します。
Evidence-bound Read-only AccessExplorer Verification
Source VerificationとRPC／Explorer Parityを記録します。
Evidence-bound Read-only AccessSecurity and Audit
Negative Test、権限、秘密情報、Incident Routeを監査します。
Guide AvailablePartner Release Checklist
Testnet Evidence、監査、運用、Release Approvalを一つのPacketにします。
Guide AvailableInstitutional Adoption Lifecycle
Evidence-gated progression from definition to operation.
定義から運用へ進む証跡基準の導入工程。
Use-case definition
Partner organization
- Required evidence
- Purpose, operating domains, value flow
- Exit condition
- Approved scope
Architecture review
Partner + Technical team
- Required evidence
- On/off-chain map, data classification
- Exit condition
- Architecture decision
Governance & compliance
Partner + JAIOS
- Required evidence
- Role matrix, legal review, custody model
- Exit condition
- Control acceptance
Testnet access
JAIOS Institutional Governance
- Required evidence
- Approved network configuration
- Exit condition
- Access evidence
Contract development
Development partner
- Required evidence
- Source, tests, dependency record
- Exit condition
- Review candidate
Security testing
Independent reviewer
- Required evidence
- Threat model, test evidence, findings
- Exit condition
- Critical findings closed
Runtime acceptance
JAIOS + Partner
- Required evidence
- Advancing head, signer set, RPC boundary
- Exit condition
- Machine decision
Operational readiness
Partner operator
- Required evidence
- Monitoring, incident, migration
- Exit condition
- Readiness checklist
Mainnet release review
Institutional governance
- Required evidence
- Release packet and approvals
- Exit condition
- Separate GO decision
Post-release monitoring
Shared responsibility
- Required evidence
- Telemetry, audit trail, incident evidence
- Exit condition
- Continuous control
Contract candidate
Public Testnet evidence
Runtime acceptance
Operational readiness
Separate Mainnet review
Mainnet activation is always a separate institutional decision supported by a complete release packet.
Governance & Responsibility
Control is explicit, bounded and auditable.
責任主体・権限・証跡を分離し、監査可能にする。
| Domain | Primary responsibility | Control focus | Evidence |
|---|---|---|---|
| Protocol governance | JAIOS Institutional Governance | Evidence and release control | Protocol acceptance record |
| Network / validator operations | Authorized network operators | Keys, quorum, continuity | Custody and health evidence |
| Token or NFT administration | External partner | Supply, mint, pause, ownership | Partner approval trail |
| Treasury and wallet custody | External partner / appointed custodian | Signing policy and segregation | Custody attestation |
| Metadata administration | External partner | Rights, permanence, personal-data exclusion | Schema and storage evidence |
| Contract implementation | Development partner | Code, tests, deployment package | Commit and test report |
| Legal / regulatory position | External partner with qualified advisers | Classification and jurisdiction | Recorded review |
| Incident response | Shared, by incident domain | Containment, evidence, migration | Incident and closure record |
Partner asset & legal design
Development implementation
JAIOS release governance
Network operations
Independent readback
Responsibility boundary
JAIOS Institutional Governance does not guarantee the economic value, market liquidity, legal classification or regulatory conformity of an external partner’s token, NFT or DApp.
外部パートナーが発行・運用する資産の経済価値、流動性、法的分類、規制適合性を保証するものではありません。
Security & Risk
Each risk requires a control and a readable record.
リスク、統制、必要証跡を一体で設計する。
Smart contract vulnerability
Independent review, unit and negative tests
Evidence · Source SHA, test report, closure logPrivate or admin key compromise
Multisig or institutional custody, separation of duties
Evidence · Custody attestation, signer registerUpgrade and ownership risk
Explicit upgrade policy, timelock where appropriate
Evidence · Admin matrix, upgrade testMetadata loss or mutation
Storage selection, integrity hash, recovery copy
Evidence · URI, digest, retention planPersonal data exposure
Keep personal data off-chain; minimize metadata
Evidence · Data classification and privacy reviewRegulatory classification
Jurisdiction-specific qualified review
Evidence · Recorded legal analysis; no platform guaranteeBridge / oracle dependency
Isolate, limit, monitor; independent security review
Evidence · Dependency inventory and incident routeOperational continuity
Monitoring, backup, migration and exit procedure
Evidence · Runbook and rehearsal evidenceSeparated roles
Multisig / custody
Contract controls
Monitoring
Incident evidence
Detect
Classify
Contain / pause
Evidence & decision
Recover / migrate
Rollback cannot erase confirmed on-chain history; migration and compensating controls must be planned.
Primary References
Canonical implementation and standards sources.
実装正本と技術標準資料。
Protocol evidence directory / プロトコル証跡一覧
Evidence is limited to chain architecture, implementation, governance and release acceptance.
本ページはチェーンの設計、実装、制度的ガバナンス、セキュリティ、受入判定に必要な技術証跡のみを扱います。法人情報、企業沿革、報道掲載はEvidenceの対象外です。
Canonical technical records
技術正本・標準・受入証跡
Canonical repositoryJAIOS-Governance / junca-social-ecosystem-chainProtocol, node, network specification, interoperability and release evidenceCore developmentConsensus Signing Safety · PR #51Persistent anti-double-signing and rollback protectionLatest core developmentValidator Release Boundary · PR #76Validators deploy before public RPC and Explorer exposureExact core sourceCommit 6de0979b972527 July 2026 · 400 / 400 automated QA PASSSource VerifiedRepository GovernanceRepository boundary and governance verificationCI VerifiedValidator Runtime ArtifactsImmutable runtime artifact and provenance verificationOperational Evidence AvailableValidator Foundation ReleaseRuntime release remains fail-closed read-only runtime acceptedGovernanceJAIOS Institutional GovernanceAuthority, separation of duties and release responsibilityMachine-verifiable boundaryRepository BoundaryCanonical inclusion, exclusion and network-state declarationSecurity policyDisclosure & Control BoundarySecurity reporting and protected-secret requirementsEthereum standardsERC Technical StandardsERC-20, ERC-721 and application-level conventionsBNB Smart ChainBSC Technical DocumentationNetwork and application referenceTRON standardsTRC Technical StandardsTRC-20 and TRC-721 referenceOperational stateEvidence MatrixCurrent deployment and verification state, separated from the completed-state specificationRelease assessmentReadiness ChecklistReview the conditions required before a controlled release decision
Readiness Classification
Machine-readable release posture.
機械判定可能なリリース準備状態。
Overall resultVERIFICATION IN PROGRESS
Any VERIFICATION IN PROGRESS item keeps release acceptance open. CONDITIONAL requires recorded conditions. NOT APPLICABLE requires a reason in the partner evidence packet.
Evidence Matrix
What is known, targeted and still under verification.
確定・目標・未検証・停止条件を分離する。
Technical reference publication / 技術書公開証跡
Commit
Build
Artifact
S3
CloudFront
DNS / TLS
Rendered QA
Current state: Source verified · Build verified · AWS publication verified · Rendered readback verified.
Public Testnet runtime / チェーンRuntime証跡
Binary
Genesis
3 Validators
Quorum
Advancing Head
Finalized Head
RPC
Explorer
Monitoring
Rollback
Current state: Core source verified · CI verified · operational evidence available · Read-only evidence access.
Certified finality controls
Strict >2/3 quorum, validator epochs, validator-set hash, Chain ID/genesis binding, duplicate/unknown signer rejection and certificate verification.
Automated quality gate
400 / 400 tests passed at core source commit 6de0979b9725, covering consensus round recovery, persistent anti-double-signing, signature verification before persistence, canonical signing payload binding, validator-node runtime, immutable validator artifacts, predeployment acceptance, and fail-closed AWS controls.
Scale profile
Throughput, finality, latency, availability and nine-validator production topology are targets, not public claims.
Partner stack
Smart-contract compatibility, token/NFT standards, SDK/API, wallet, compiler and verification toolchain.
Ethereum / ERC, BSC & TRON control plane
Route validation, message-state engine, simulation, replay controls and testnet bridge contract. No deployment or asset movement.
Read-only evidence access
Validator addresses, advancing/finalized heads, public RPC, Explorer parity, monitoring, rollback and independent runtime readback remain open.
Technical Glossary
A shared language for institutional implementation.
制度的実装のための共通言語。
Terms are defined for this controlled public-testnet reference. They do not replace jurisdiction-specific legal, regulatory or technical review.
Acceptance evidence
A recorded artefact used to determine whether a defined release condition has been met.
定義済みのリリース条件を満たしたか判定するための記録済み証跡。
Asset administration
Institutional control of supply, minting, pausing, ownership and operational policy for a digital asset.
デジタル資産の供給、発行、停止、所有権、運用方針に対する制度的統制。
Candidate Chain ID
A reserved identifier for controlled configuration and testing; it is not proof of a publicly operating network.
統制された設定・試験用の予約識別子。公開稼働ネットワークの証明ではない。
Finality
The point at which a transaction is treated as sufficiently irreversible under a defined confirmation policy.
定義済み確認方針に基づき、取引を十分に不可逆と扱う時点。
Interoperability route
A governed message and asset pathway between explicitly identified networks.
明示されたネットワーク間のメッセージ・資産移動を統制する経路。
JAIOS Institutional Governance
The approved public designation for JUNCA protocol release, issuance and operational governance responsibility.
JUNCAのプロトコル公開、発行、運用統制責任を示す承認済み対外表記。
Protocol Validation Environment
A public-testnet notice identifying the network as a protocol-validation environment with test assets separated from Mainnet-issued JSEC.
本Public Testnetがプロトコル検証環境であり、テスト資産をMainnet発行のJSECと区分することを示す公開表示。
Public Testnet
A non-mainnet environment intended for controlled public verification and evidence collection.
統制された公開検証と証跡収集を目的とするMainnet以外の環境。
Relayer quorum
The minimum number of independently verified relayer signatures required before a cross-network action may proceed.
クロスネットワーク処理の実行前に必要な独立検証済みRelayer署名の最小数。
Replay protection
Controls that prevent a message, source transaction or nonce from being executed more than once.
メッセージ、送信元取引、Nonceの重複実行を防止する統制。
Release gate
A fail-closed decision point that blocks progression until required evidence and approvals are present.
必要証跡と承認が揃うまで進行を停止するFail-Closed型の判断点。
Runtime acceptance
Evidence-based confirmation that deployed infrastructure behaves within approved network and security boundaries.
配置済みインフラが承認されたネットワーク・セキュリティ境界内で動作することの証跡ベース確認。
Documents & source records
Read the underlying material.
この章の根拠資料・仕様・検証記録
Canonical foundation and auxiliary gateway are explicitly separated.
正規開発基盤と補助ゲートウェイを明確に分離して表示します。
Reproducible blockchain protocol development environment merged to main.
再現可能なブロックチェーン開発環境を正規基盤としてmainへ統合済みです。
Inspect PR #237 ↗Custom GPT Gateway remains auxiliary, unmerged and not deployed or registered.
Custom GPT Gatewayは補助機能であり、未統合・未配置・未登録です。
Inspect PR #236 ↗Governed readbackPublic Testnet · Read-only · Protocol Validation Environment
Measured runtime evidence, published from the current Explorer readback.
実測済みの運用証跡を、推測を加えずに表示します。
Explorer observed · 2026-08-04T23:47:10.971480+00:00
- Network
- VERIFIED
- Runtime
- READY · READ-ONLY
- Finality
- 3 / 3
- Finalized Height
- 10360
- Finalized Block Hash
- 0x43de10d626627478b257083bb50180710ef6cec11e27bc450f6368e440f679e4
- Certificate Hash
- 0xfb4cbeafff162fa04fc8eceac9e5a489617ff05e469eae53399fd6ea2c2cadab
- State Root
- 0x4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945
- Chain ID
- 20260723
- Client Version
- JUNCA-Social-Ecosystem-Chain/public-testnet-python-v1
- Runtime Artifact Commit
- 42a64411ee406dfda814cf519a74478f5669cb7b
- Genesis SHA-256
- 285f1aa2610ec98fba598aa3c8e721b54daeeddf2047b7f809f57c63db98dc95
- Node Artifact SHA-256
- cf1ca0039d7855e5dc9cd2bda00d8ea691bb702966fa538c4510195a8926317f
- Transactions
- 0
- Peer Count
- 2
- Block Timestamp
- 2026-08-04T23:47:00.000Z
Mainnet Changed: false · Assets Moved: false · Bridge Activated: false · Mainnet Activation Authorized: false.