Home Why BCCS Protocol Access Contracts Implementation BioClearing Audit Docs Buy License
BCCS/Protocol Extension/BioClearing
REGISTRY LAYER BCCS Global Registry — Technical Architecture

The clearing layer above BCCS verification.

BCCS answers a point-in-time question: what is the verified state of this biological asset? The BCCS Global Registry answers a different question: has the clearing obligation on this territorial asset reached finality?

One protocol. Two layers. One records truth. The other records settlement. Together they form the complete data stack for territorial bio-capital — from individual verification queries on Base L2 to sovereign-grade clearing infrastructure across 175 jurisdictions.

The BAIN ID is the bridge. What begins as a 21-character verification identifier on BCCS becomes the atomic unit of a global clearing registry.
Open Registry → Read the Architecture ↓
01 — Protocol Stack

Three layers. One continuous architecture.

The BCCS protocol is not a single system. It is a vertical stack where each layer produces data consumed by the next. Verification produces state. Registry records the state progression. Clearing marks the progression as final. Each layer is independently operable, collectively indispensable.

Layer III

Clearing — BCCS Global Registry

Records clearing-state progression of every registered Territorial Bio-Asset Record. Seven-state irreversible ratchet. Tri-jurisdiction hosting (HK · UAE · SG). Institutional-grade tamper evidence via Merkle trees. The settlement layer.

OPERATIONAL bioclearing.global
Layer II

Registry — TBAR Object Store

The Territorial Bio-Asset Record object: GeoJSON boundary, measurement dataset, verification records, legal vehicle, exclusions, capital_eligibility flag. BAIN ID as primary key across all layers. Append-only, Merkle-anchored.

OPERATIONAL Tri-jurisdiction sync
Layer I

Verification — BCCS Protocol on Base L2

ERC-20 verification unit ($BCCS), soulbound ERC-721 Node Licenses, three-tier oracle consensus (satellite, IoT, inspection), Proof-of-Physical-State attestations, on-chain query API. The trust-machine for biological state.

LIVE ON BASE bccs.bio

A verification query on BCCS returns the current verified state of a biological asset at a moment in time. A registry query on BioClearing returns the clearing history of that asset across all time. The difference is not semantic. It is the difference between knowing a fact and having a record of the fact.


02 — The Global Standard

BAIN ID — the atomic unit of every layer

The 21-character Bio-Asset Identification Number is the primary key of the entire protocol. It is issued on BCCS at initial observation, persists through all verification states, extends seamlessly into the clearing registry, and survives every transition — including reversal and re-entry. One identifier. Every layer. Forever.

RU-KAR-PEG-001-7
Example: Russia · Karelia · Pegozer boreal · Sequence 001
RU
Country
ISO 3166-1 alpha-2. 175 sovereign territories addressable.
KAR
Region
Three-character sub-national region code assigned by sovereign node.
PEG
Territory
Three-character identifier for the specific bio-asset territory.
001
Sequence
Three-digit sequential number within territory. Up to 999 TBARs per territory.
7
Check
Single-digit integrity check, catches transcription errors.

Why this matters architecturally. When a node operator on BCCS submits a verification attestation, the BAIN ID in their payload is identical to the BAIN ID in the BioClearing registry. There is no translation layer, no lookup table, no identifier mapping. An auditor querying RU-KAR-PEG-001-7 on BCCS and the same string on BioClearing is querying the same asset through two different lenses — verification state and clearing state.

This is how institutional data infrastructure compounds. Every layer of the protocol stack addresses the same asset by the same name. The BAIN ID is the CUSIP of territorial bio-capital.


03 — Registry Object Schema

TBAR — the record object itself

Every entry in the BCCS Global Registry conforms to the Territorial Bio-Asset Record schema. Nine canonical fields. Each field is either queryable by auditor, consumable by smart contract, or both. The schema is append-only — once written, a field’s value enters the state history but is never overwritten.

bain_id
string(21)
Primary key. Globally unique 21-character identifier. Immutable from the moment of assignment.
coordinates
GeoJSON
Polygon boundary at 10-metre precision. The territorial footprint, machine-readable and unambiguous.
clearing_state
enum
Current state: 1 Observed · 2 Measured · 3 Verified · 4 Registered · 5 Final · R Reversed.
state_history
append-only
Timestamped log of every transition with Merkle-tree anchoring. Auditors trace full provenance without gaps.
asset_layers
JSON map
Structured data per bio-stock: carbon, biomass, freshwater, biodiversity. Each independently measured and verified.
verification_records
array
Three-plus independent verifier IDs, methodology references, convergence scores. Single-verifier records are never sufficient.
legal_vehicle
reference
Special Purpose Company or sovereign entity encapsulating the territory. Jurisdiction-specific. Registry records, does not create.
exclusions
array
Explicitly declared out-of-scope elements: heritage sites, speculative mineral claims, political claims. Transparency requirement.
capital_eligibility
boolean
True only when clearing_state = 5 and no reversal conditions are active. The flag institutional capital queries.

The TBAR schema deliberately excludes fields that would capture it. There is no price field. No market-maker reference. No tokenisation URI. No regulatory classification. The registry is infrastructure, not commentary. Market participants query TBAR fields and construct their own instruments. The registry records. It does not opine.


04 — State Machine Mechanics

Seven states. Atomic transitions. No rollback.

The BCCS Global Registry implements a strict finite state machine. Transitions are atomic — either all conditions are met and the state advances, or nothing changes. Partial transitions do not exist. Forward motion is irreversible; the only path backward runs through State R.

1

Observed

Territorial footprint declared. BAIN ID assigned. GeoJSON polygon submitted and validated for geometric correctness. No measurement claims yet, no verification, no legal vehicle. An observed TBAR is a reserved address — a slot in the registry awaiting content.

TriggerRegistration Tx
2

Measured

All declared asset layers measured using protocol-compliant instrumentation. Measurement dataset cryptographically hashed and submitted to registry. Hash anchored in state_history. Raw data remains with the measurement operator; only the hash and methodology reference are registry-public.

TriggerData Submission
3

Verified

Three or more accredited verifiers independently review the measurement dataset using published BCCS methodologies. Their convergence scores must fall within protocol tolerance. Convergence, not consensus — honest verifiers cannot collude on their errors. The verification_records array is populated.

Trigger3+ Convergence
4

Registered

Legal vehicle operational under its jurisdiction’s law. Exclusions declared. All TBAR fields populated and frozen against further edits (new values enter as new state_history entries). The registry record is structurally complete.

TriggerLegal Vehicle Live
5

Final

Continuous monitoring layer reports no degradation. All preceding states hold uncontested. capital_eligibility flag set to true. Institutional capital can now interact with the TBAR — through investment vehicles, insurance contracts, or sovereign balance-sheet integration — with clearing status as a settled fact.

TriggerMonitoring + Hold
R

Reversed

Triggered by measurement failure, verifier disagreement surfaced post-registration, legal vehicle collapse, or physical degradation detected by continuous monitoring. Reversal is transparent and permanent in state_history. A reversed TBAR can re-enter the sequence only by restarting from State 1 — same BAIN ID, fresh progression.

TriggerIntegrity Failure

The ratchet is not a design preference. It is the architectural enforcement of institutional trust. Forward-only motion with transparent reversal is the minimum condition under which sovereign-grade capital can rely on the record.


05 — Oracle-to-Registry Pipeline

How BCCS verification becomes clearing state

The bridge from on-chain verification (Base L2) to clearing registry (tri-jurisdiction) is a deterministic pipeline. No human judgement at transition points. The pipeline consumes oracle attestations and produces state transitions.

STEP 01

Oracle Attestation

Node operator on BCCS submits Proof-of-Physical-State attestation for a specific BAIN ID with measurement evidence hash.

IN: evidence hash
OUT: on-chain attest
STEP 02

Consensus Check

Registry waits for three-tier convergence from satellite, IoT, and inspection oracles. If achieved within protocol tolerance, proceeds.

IN: 3 oracle feeds
OUT: convergence score
STEP 03

State Transition

Registry executes atomic state advance on the TBAR. New state_history entry with timestamp, oracle references, and Merkle-tree root.

IN: convergence pass
OUT: state++ event
STEP 04

Sync Propagation

Transition replicated synchronously to UAE and Singapore mirrors. Cross-jurisdiction finality achieved within seconds. Merkle root available for audit.

IN: state++ event
OUT: global finality
bccs-registry — example state transition
# Oracle attestation triggers State 2 → State 3 transition
 
> POST /registry/tbar/RU-KAR-PEG-001-7/attest
  oracle: 0x7a3f...9c12
  tier: satellite_sentinel2
  evidence_hash: 0xb86174c4...eeba17a7
 
> CONSENSUS_CHECK
  tier_1_satellite:  PASS · confidence 0.94
  tier_2_iot_ground: PASS · confidence 0.91
  tier_3_inspection: PASS · confidence 0.96
  convergence:     0.94 (> 0.85 threshold)
 
> STATE_TRANSITION
  bain_id: "RU-KAR-PEG-001-7"
  from:    2 (Measured)
  to:      3 (Verified)
  timestamp: "2026-04-16T09:14:00Z"
  merkle_root: "0x44B46f9D...4b66FBd"
 
> SYNC_STATUS
  hk_primary:  COMMITTED
  uae_mirror:  COMMITTED (+0.8s)
  sg_mirror:   COMMITTED (+1.2s)
  finality:    GLOBAL

06 — Deployment Architecture

Tri-jurisdiction hosting. Sovereign-neutral by design.

The registry operates from three independent jurisdictions with synchronous replication. No single government can compel unilateral data modification. Each jurisdiction is accessible to BRICS+ and Western institutional capital alike. Neutrality is not a policy — it is a physical property of the architecture.

Primary
Hong Kong SAR
KRYONIS Sovereign Systems Ltd
Primary registry node. Registered entity. Common-law commercial jurisdiction with settled precedent on data infrastructure operators. Gateway for Greater China and Asia-Pacific capital flows.
Primary Node Common Law Asia-Pac
Mirror
United Arab Emirates
Synchronous replica
Full synchronous mirror with sub-second replication latency. Strategic access for MENA sovereign wealth, Gulf institutional capital, and African bio-capital deployment. DIFC-compatible operating posture.
Sync Mirror DIFC-ready MENA Gateway
Mirror
Singapore
Synchronous replica
Full synchronous mirror. Institutional access point for ASEAN bio-capital, multilateral treaty-compliant data operations, and Western allocator due-diligence workflows. MAS-aware infrastructure posture.
Sync Mirror ASEAN Gateway MAS-aware

Each node is functionally identical. A query to hk.registry.bioclearing.global returns the same TBAR state as sg.registry.bioclearing.global. Institutional clients route to whichever jurisdiction aligns with their compliance posture. The data is the same everywhere; the legal wrapper around querying it varies by preference.

175
Sovereign Territories Addressable
3
Hosting Jurisdictions
< 2s
Cross-Jurisdiction Finality
21
Character BAIN ID Standard

07 — Sovereign Deployment Model

Every state operates its own node

The BCCS Global Registry is not an extraterritorial database. Every sovereign operates its own node within its own jurisdiction, registering only its own TBARs. The protocol connects nodes — it does not centralise data. This is the same architecture as the Internet: every autonomous system operates its own infrastructure, and the protocol is what makes interoperation possible.

STEP 01

Sovereign Onboarding

The state (via its environment ministry, sovereign wealth fund, or designated statutory body) signs the Sovereign Operator Agreement with KRYONIS Registry Services. The SOA defines: node operating responsibilities, data-residency commitments, dispute resolution mechanism, and protocol compliance obligations.

  • Output: operational sovereign node identity
  • Output: reserved country code block in BAIN ID namespace
  • Output: access credentials to tri-jurisdiction sync layer
STEP 02

Measurement Infrastructure Deployment

The sovereign deploys the six-layer measurement stack on its own territory under its own jurisdiction. Satellite subscriptions, LiDAR flight schedules, IoT sensor networks, AI analytics compute, ground-truth verifier accreditation, continuous monitoring infrastructure. The sensors belong to the state. The standards belong to the protocol.

  • Satellite data partnerships (Sentinel, Landsat, Planet, national agencies)
  • IoT deployment plan with local telecoms and ground operators
  • Accreditation pathway for national verifier cohort
STEP 03

First TBAR Registration

The sovereign selects a pilot territory. GeoJSON polygon submitted to the registry. BAIN ID assigned (e.g. RU-KAR-PEG-001-7). Clearing state initialised at 1 (Observed). First pilot typically: one territory, one bio-stock, twelve months from Observed to Final.

  • Pilot scope: single territory, single primary asset layer
  • Timeline: 3 months to State 2, 6 to State 3, 9 to State 4, 12 to State 5
  • Deliverable: first fully-cleared TBAR on sovereign node
STEP 04

Capital Integration

With one or more TBARs at State 5, the sovereign can expose clearing states to institutional capital. Investment vehicles, insurance contracts, balance-sheet integration, sovereign-to-sovereign clearing flows. The registry does not execute these — it provides the queryable record that makes them possible.

  • Sovereign wealth fund due-diligence via TBAR queries
  • Multilateral insurer risk pricing from state_history
  • Cross-sovereign bio-asset instruments via BAIN ID references
STEP 05

Network Expansion

First TBAR becomes second, then tenth, then hundredth. The sovereign node stabilises into normal operation. At network scale, territorial bio-capital becomes a queryable asset class — not because any single state drove the adoption, but because each operated its own node under the same standard.

  • Participation in protocol governance via Advisory Council seat
  • Contribution to methodology evolution and verifier standards
  • Position within the growing sovereign bio-capital market

What the protocol requires of the sovereign: operate the node honestly, follow the measurement standards, accept the ratchet, tolerate reversal when integrity fails. What the protocol does not require: surrender data to any foreign entity, adopt any currency regime, integrate with any specific trading venue, or accept any geopolitical alignment. The registry is genuinely neutral — it records what is, not what anyone wishes to be true.


Enter the Registry

From BCCS verification to global clearing infrastructure

175 sovereign territories addressable. Every latitude, every jurisdiction, every biome. Explore the global registry, view the BAIN ID for your territory, and initiate sovereign deployment inquiry.

Operated by KRYONIS Sovereign Systems Limited · Hong Kong SAR