TECHNICAL Implementation Architecture

How BCCS verifies biological state at sovereign scale

The complete engineering blueprint for the BCCS verification network. From satellite observation to on-chain attestation — every layer, every component, every data flow.

01 — System Overview

End-to-end verification architecture

BCCS operates as a five-layer stack. Raw physical observations enter at the bottom. Cryptographically attested biological state exits at the top. No single layer can be compromised without detection by adjacent layers.

Data Flow — Observation to Attestation
Layer 1
Physical Observation
Satellites, IoT sensors, field inspectors
→
Layer 2
Data Ingestion
Normalization, timestamping, cryptographic hashing
→
Layer 3
Oracle Consensus
PoPS 2-of-3 multi-source verification
→
Layer 4
State Transition
BAIN ID lifecycle update on Base L2
→
Layer 5
API & Query
REST/WebSocket — AI agents, institutions, smart contracts
02 — Tier 1: Satellite Remote Sensing

Orbital observation layer

The first tier of the PoPS consensus mechanism. Satellite-derived spectral data provides continuous, tamper-resistant observation of biological assets at continental scale.

PRIMARY SOURCE

Copernicus Sentinel-2

European Space Agency constellation. Two satellites (2A/2B) providing global coverage every 5 days. 13 spectral bands, 10m spatial resolution in visible/NIR. Open access, zero cost.

Key indices derived: NDVI (vegetation health), NDWI (water content), NBR (burn severity), EVI (enhanced vegetation), LAI (leaf area index).

SECONDARY SOURCE

Landsat 8/9 (USGS/NASA)

30m resolution, 16-day revisit cycle. Thermal infrared bands critical for permafrost surface temperature monitoring. 40+ year archive enables long-term baseline comparison. Open access, zero cost.

HIGH-RES SOURCE

Planet Labs (SkySat / PlanetScope)

Daily global imaging at 3–5m resolution. Sub-meter tasking available via SkySat. Used for targeted verification of specific assets when Tier 3 inspection is pending or disputed. Commercial API — licensed per area of interest.

PROCESSING

Spectral Analysis Pipeline

Raw satellite imagery is processed through a standardized pipeline:

  • Atmospheric correction — Sen2Cor (ESA) for Sentinel-2, LaSRC for Landsat
  • Cloud masking — s2cloudless (Sentinel Hub) + Fmask (Landsat)
  • Index computation — NDVI, NDWI, NBR, EVI, custom indices per asset class
  • Change detection — multi-temporal comparison against BAIN ID baseline
  • Anomaly flagging — statistical deviation triggers Tier 2/3 verification request

Tools: Google Earth Engine, Sentinel Hub API, STAC (SpatioTemporal Asset Catalog), rasterio, GDAL.

OUTPUT

Tier 1 Attestation Object

Each observation produces a cryptographically signed JSON attestation containing: BAIN ID reference, observation timestamp (UTC), satellite source ID, spectral index values, confidence score (0.0–1.0), SHA-256 hash of source imagery, and deviation flag (boolean).

Attestation is submitted to the Oracle Consensus layer. A single Tier 1 observation cannot trigger a BAIN ID state transition alone — requires corroboration from Tier 2 or Tier 3.

03 — Tier 2: Ground-Based IoT Sensor Network

Terrestrial measurement layer

The second tier operates at ground level. Sensors measure physical parameters that satellites cannot observe: subsurface temperature, soil chemistry, gas flux, microbial activity. Each sensor node is GPS-tagged, tamper-evident, and transmits encrypted data to the ingestion layer.

SENSOR TYPES

Modular Sensor Stack

Sensor deployment is asset-class-specific. A permafrost monitoring installation uses different instruments than a tropical forest canopy station. The BCCS sensor taxonomy defines required and optional sensors per BAIN ID asset class.

  • Soil temperature probes — thermistor arrays at 0.5m, 1m, 2m, 5m depths. Critical for permafrost active layer monitoring.
  • Soil moisture sensors — TDR (Time Domain Reflectometry) and capacitance-based. Volumetric water content at multiple depths.
  • Gas flux chambers — CO₂ and CH₄ flux measurement. Eddy covariance or closed-chamber method. Essential for carbon accounting verification.
  • Dendrometers — tree growth rings, diameter change. Sub-millimeter resolution for biomass accumulation tracking.
  • Weather stations — air temperature, humidity, precipitation, wind speed, solar radiation. Baseline environmental context.
  • Acoustic sensors — biodiversity monitoring via bioacoustic analysis. Species identification, ecosystem health indicators.
  • Water quality probes — pH, dissolved oxygen, turbidity, conductivity. For aquatic and wetland BAIN IDs.
HARDWARE

Node Hardware Architecture

Each ground station operates as an autonomous edge computing unit:

  • Compute — ARM-based SBC (Single Board Computer). Runs data collection daemon, local preprocessing, encryption, and uplink management.
  • Connectivity — LoRaWAN (primary, long-range/low-power), cellular fallback (4G/5G), satellite uplink (Iridium/Starlink) for remote deployments.
  • Power — solar panel + battery bank for off-grid operation. Power budget designed for 30+ days of autonomous operation without solar input (arctic winter scenario).
  • Enclosure — IP67 rated. Operating range -40°C to +60°C. Tamper-evident seals with accelerometer-based intrusion detection.
  • GPS/GNSS — precise geolocation with sub-meter accuracy. Timestamp synchronized via NTP over satellite.
DATA PROTOCOL

Sensor-to-Chain Data Flow

Sensor readings follow a standardized ingestion protocol:

  • Sample — sensor reads at configurable interval (default: 15 minutes)
  • Preprocess — on-device outlier filtering, unit normalization, quality flagging
  • Package — JSON payload with sensor ID, BAIN ID reference, timestamp, readings array, device health metrics
  • Sign — Ed25519 digital signature with device-specific private key (stored in hardware security module)
  • Encrypt — AES-256-GCM encryption before transmission
  • Transmit — to BCCS ingestion endpoint via LoRaWAN gateway or direct cellular/satellite uplink
  • Verify — ingestion layer validates signature, decrypts, checks timestamp freshness, stores in time-series database
OUTPUT

Tier 2 Attestation Object

Aggregated sensor data produces a Tier 2 attestation: BAIN ID reference, time window (UTC start/end), sensor node IDs contributing, parameter readings (mean, min, max, std dev), device health score, data completeness percentage, SHA-256 hash of raw dataset, and deviation flag.

04 — Tier 3: Physical Inspection

Human verification layer

The third tier is the hardest to fake. Accredited inspectors physically visit the biological asset, collect evidence, and submit GPS-stamped, timestamped documentation. This tier resolves disputes between Tier 1 and Tier 2 and provides the highest confidence attestation.

INSPECTOR PROTOCOL

Standardized Field Verification

  • Accreditation — inspectors must hold a valid BCCS Inspection Credential (soulbound, revocable). Training and certification through KRYONIS Lab MSV Certification program.
  • Assignment — verification requests are assigned pseudonymously — inspectors do not know which node operator requested the inspection, preventing collusion.
  • Evidence capture — geotagged photographs (EXIF verified), video documentation, soil/water/tissue sampling where applicable, field measurement data.
  • GPS trajectory — continuous GPS logging during site visit. Track must demonstrate physical presence within BAIN ID boundary polygon.
  • Timestamp authority — all evidence timestamped via RFC 3161 trusted timestamping service.
  • Submission — evidence package uploaded to BCCS within 48 hours. Package includes: inspection report (structured form), evidence files, GPS track, inspector credential ID.
ANTI-FRAUD

Inspection Integrity Mechanisms

  • Random audit — 10% of inspections are re-inspected by a second independent inspector within 14 days
  • Cross-reference — Tier 3 evidence is automatically cross-validated against concurrent Tier 1 and Tier 2 data. Discrepancies trigger dispute resolution.
  • Stake at risk — inspectors stake $BCCS against their attestations. False or negligent reports result in slashing.
  • Reputation scoring — cumulative accuracy score affects future assignment priority and earning potential.
OUTPUT

Tier 3 Attestation Object

Inspector evidence produces the highest-weight attestation: BAIN ID reference, inspection date/time (UTC), inspector credential ID (anonymized in public record), GPS boundary confirmation, evidence file hashes, field measurements, condition assessment (structured rubric), confidence score, and inspector stake amount.

05 — Oracle Consensus Engine

Proof-of-Physical-State (PoPS)

The consensus engine receives attestation objects from all three tiers, evaluates agreement, computes a composite confidence score, and determines whether a BAIN ID state transition is warranted. This is the core of the protocol.

CONSENSUS RULE

2-of-3 Multi-Source Agreement

A BAIN ID state transition requires attestation agreement from at least two of three tiers. No single data source — regardless of confidence — can unilaterally change biological state on-chain. This is the fundamental security property of PoPS.

  • Tier 1 + Tier 2 agree — state transition proceeds. Tier 3 inspection scheduled for confirmation within 90 days.
  • Tier 1 + Tier 3 agree — state transition proceeds. Tier 2 sensor calibration review triggered.
  • Tier 2 + Tier 3 agree — state transition proceeds. Tier 1 observation anomaly flagged for review.
  • All three disagree — state remains unchanged. Dispute resolution protocol initiated. All three tiers re-assessed within 30 days.
CONFIDENCE SCORING

Composite Confidence Calculation

Each tier attestation carries a confidence score (0.0–1.0). The Oracle Engine computes a weighted composite:

C = (w1 × T1) + (w2 × T2) + (w3 × T3)

Default weights: w1=0.30 (satellite), w2=0.30 (IoT), w3=0.40 (inspection). Weights are adjustable per asset class — permafrost assets may weight Tier 2 (subsurface temperature) higher; forest assets may weight Tier 1 (canopy spectral analysis) higher.

State transition requires C ≥ 0.70. Scores below threshold are flagged for additional evidence collection.

SLASHING

Economic Security via Penalty

Node operators and inspectors who submit attestations that are later contradicted by multi-tier consensus face economic penalties:

  • Minor deviation (within tolerance) — warning, reputation score reduction
  • Major deviation (outside tolerance, single instance) — 10% stake slash, 30-day probation
  • Fraudulent submission (proven intent) — 100% stake slash, permanent credential revocation, slashed tokens burned

Slashed tokens are permanently burned — reducing total circulating supply. This creates a direct economic link between network integrity and token scarcity.

06 — Software Architecture

The engineering stack

Every component of the BCCS verification network is built on open, auditable, and composable infrastructure.

Smart Contracts

On-Chain Layer

LanguageSolidity 0.8.x
FrameworkOpenZeppelin
ChainBase L2 (OP Stack)
TokenERC-20 ($BCCS)
License NFTERC-721 + EIP-5192
BAIN RegistryCustom contract
GovernanceSafe Multisig → DAO
VerificationBaseScan source verified
Backend Services

Oracle & API Layer

RuntimeRust / Node.js
API FrameworkAxum (Rust) / Express
DatabasePostgreSQL + TimescaleDB
CacheRedis
QueueNATS / RabbitMQ
GeospatialPostGIS
Satellite DataSTAC API + GEE
InfrastructureDocker / Kubernetes
Sensor Network

Edge & IoT Layer

Edge OSLinux (Yocto / Buildroot)
FirmwareRust / C (embedded)
ProtocolMQTT over TLS
ConnectivityLoRaWAN / 4G / Sat
CryptoEd25519 + AES-256-GCM
HSMATECC608B
Time SyncNTP over satellite
PowerSolar + LiFePO4
bccs-api — verification attestation schema
# BAIN ID state transition attestation — on-chain record

{
  "bain_id":         "RUS-PF-8a4c2e1d7b3f-B2D9",
  "asset_class":     "Permafrost",
  "region":          "RUS",
  "previous_state":  "Verified-Stable",
  "new_state":       "Verified-Degrading",
  "composite_score": 0.87,
  "tier_1": {
    "source":       "Sentinel-2B",
    "index":        "NDVI anomaly -0.12",
    "confidence":   0.82,
    "deviation":    true
  },
  "tier_2": {
    "sensors":      12,
    "temp_2m":      "-1.2°C (baseline: -3.8°C)",
    "ch4_flux":     "elevated +340%",
    "confidence":   0.91,
    "deviation":    true
  },
  "tier_3":          "Pending — scheduled within 90 days",
  "consensus":       "2-of-3 confirmed (T1+T2)",
  "tx_hash":         "0x7a3f...9c12",
  "block":           28441067
}
07 — API Specification

Machine-readable biological state

Every BAIN ID is queryable via REST and WebSocket interfaces. AI agents, smart contracts, institutional dashboards, and regulatory systems consume verified biological state through a unified API.

REST API

Core Endpoints

  • GET /v1/bain/{id}/state — current verified state of a BAIN ID
  • GET /v1/bain/{id}/history — full state transition history with attestations
  • GET /v1/bain/{id}/attestations — all tier attestations for a BAIN ID
  • POST /v1/bain/{id}/verify — submit new attestation (node operators only)
  • GET /v1/bain/search — query by region, asset class, state, confidence threshold
  • GET /v1/stats/network — active nodes, total BAIN IDs, verification volume
WEBSOCKET

Real-Time State Events

ws://api.bccs.bio/v1/stream

Subscribe to real-time state transition events. Filter by region, asset class, or specific BAIN IDs. Used by AI agents monitoring portfolio exposure, insurance parametric triggers, and regulatory compliance dashboards.

AUTHENTICATION

API Access Control

Public read access for basic state queries (rate-limited). Authenticated access via API key for institutional consumers. Node operators authenticate via wallet signature (EIP-4361 / Sign-In with Ethereum). All queries priced in $BCCS — creating protocol-native demand proportional to verification consumption.

08 — Founding Oracle Pilot

Sovereign-scale deployment blueprint

The Founding Oracle is the first sovereign-scale deployment of BCCS verification infrastructure. A national government or institutional partner deploys PoPS against a defined biological asset class — producing the protocol's first verified case study.

MONTH 1–2 — SCOPING & LEGAL

Asset selection and framework agreement

Define target biological asset class (e.g. permafrost zone, national forest reserve, marine protected area). Execute cooperation agreement between sovereign entity and KRYONIS. Establish BAIN ID taxonomy for selected asset class. Define verification parameters and success criteria.

MONTH 2–4 — INFRASTRUCTURE DEPLOYMENT

Sensor network and satellite pipeline

Deploy IoT sensor stations across pilot area. Configure Sentinel-2 and Landsat observation windows. Establish Planet Labs commercial tasking for high-resolution verification. Connect sensor network to BCCS ingestion layer. Register pilot area BAIN IDs on Base.

MONTH 4–6 — CALIBRATION & BASELINE

Data collection and system calibration

Collect 60–90 days of continuous multi-tier data. Establish baseline state for each BAIN ID. Calibrate confidence scoring weights for asset class. Train and accredit local Tier 3 inspectors. Validate PoPS consensus against known ground truth.

MONTH 6–8 — LIVE VERIFICATION

Operational PoPS verification

Activate live verification cycle. First on-chain state transitions recorded. API serving verified biological state. Dashboard operational for sovereign partner. Node operators earning $BCCS for verification work.

MONTH 8–12 — CASE STUDY & SCALING

Publication and expansion planning

Produce published case study with sovereign partner co-authorship. Present results at international forums. Define expansion roadmap — additional asset classes, additional regions. Establish pathway to permanent national verification infrastructure.

The Founding Oracle produces three things simultaneously

1. Scientific credibility — a published, peer-reviewable case study proving PoPS verification works at sovereign scale.
2. Institutional reference — a named sovereign partner whose participation de-risks the protocol for subsequent adopters.
3. Live infrastructure — a permanent, operational verification network that continues generating verified biological state data beyond the pilot period.

09 — Security Architecture

Trust assumptions and attack surfaces

BCCS is designed under the assumption that any individual data source, sensor, inspector, or node operator may be compromised. The protocol's security derives from multi-source consensus, economic penalties, and cryptographic verification — not from trusting any single actor.

THREAT MODEL

Addressed Attack Vectors

  • Satellite spoofing — mitigated by Tier 2/3 cross-validation. Fabricating satellite imagery that also matches ground sensor data and physical inspection is economically infeasible.
  • Sensor tampering — mitigated by tamper-evident hardware, HSM-signed data, and cross-validation with Tier 1/3. Replacing a sensor requires physical access and produces detectable signature discontinuity.
  • Inspector collusion — mitigated by pseudonymous assignment, random re-inspection, stake-at-risk, and cross-tier validation. Colluding with a sensor operator AND a satellite provider simultaneously is not practically achievable.
  • Node operator manipulation — mitigated by PoPS consensus rules (no single operator can force state transition), slashing for false attestations, and soulbound identity (operators cannot hide behind disposable accounts).
  • AI-generated fake evidence — mitigated by multi-source requirement. AI can generate convincing satellite imagery OR sensor data OR inspection photos — but generating all three in mutual agreement requires compromising physically separate, cryptographically independent systems.
SMART CONTRACT

On-Chain Security

All contracts built on audited OpenZeppelin libraries. Ownership held by Safe multisig (multi-signature wallet requiring multiple authorized signers). Pausable in emergency. Internal security review completed April 15, 2026 — no critical or high severity issues found. Full report →