The layer below every platform

From voice to economic execution.

Semantos is the infrastructure layer between intent and on-chain settlement — cell-based, identity-native, blockchain-settled. Right now, the truth about your business is distributed across systems that don't agree, owned by platforms that profit from your dependency, and too fragile to survive the next API change. Semantos is the substrate — the layer below every platform — that changes the ground state.

Get in touch →
“fix the tap”
Voice
hat resolved
Identity
Intent
NLU
Cell created
Semantic object
Policy eval
VM kernel
Dispatch
Cross-domain
⛓ Anchored
BSV mainnet
The status quo

The world runs on distributed chaos.

Every organisation you've worked with carries the same invisible tax. Somewhere between the meeting where a decision was made, the email chain that followed, the spreadsheet that became canonical, and the platform that got updated last — the truth got distributed. Not lost. Distributed. Spread across enough systems that nobody is quite sure where it lives, who owns it, or what it actually says.
Distributed state · coordination burden

Nobody knows what's real.

Across any workflow involving more than one system, truth exists in multiple copies — each drifting from the others. A job dispatched to a contractor exists as a ticket in the PM tool, a draft in the accounting platform, an unread email in someone's inbox, and a push notification on a phone. Each is a different version of what happened. There is no canonical record. Reconciliation is manual, expensive, and usually wrong after enough time passes.

And when two parties need to coordinate — a business and a contractor, a landlord and a tenant, a company and a regulator — the entire coordination infrastructure has to be rebuilt from scratch. Custom integration. Custom trust model. Custom reconciliation logic. Every time.

Work order #4821 — one job, five versions
PM tool dispatched → in progress
Accounting draft invoice — awaiting PO
Owner's inbox approval email — unread
Contractor app accepted · en route
Compliance log no record
source of truth: undefined
Semantic degradation · auditability gap

Data crosses boundaries.
Meaning doesn't.

Every system boundary destroys context. "Urgent — tenant has no hot water, please fix before 5pm" becomes a priority-3 ticket, becomes a work order type code, becomes a database row with a status integer. The urgency is gone. The causal chain — who said what, what was agreed, who authorised the spend — dissolves at every handoff.

Audit trails are owned by the platforms that create them. Accessible only while your subscription is active. Siloed behind their data model. When something goes wrong — a dispute, a liability question, a compliance audit — you can prove what a platform recorded. You cannot prove what actually happened.

Meaning lost in transit
natural language
"Urgent — tap dripping, tenant has no hot water, fix before 5pm"
boundary: NLP → ticket schema
ticket system
type: MAINTENANCE
priority: 3 · status: OPEN
urgency · context · deadline
boundary: ticket → work order
work order DB row
id: 4821 · code: 0x04 · status: 2
who approved · why urgent · tenant
Platform lock-in · dependency · data silos

Your data lives in
someone else's house.

Every useful platform you adopt is a sticky platform. It builds value by accumulating your data, your relationships, your workflows — in its own model, not yours — and then becomes the chokepoint. The more you depend on it, the more it can charge. Your customers live in a CRM. Your finances live in an accounting platform. Your staff live in an HR tool. Your org structure lives in an identity provider.

You can export a CSV. You cannot take the meaning. Leaving costs more than staying. The platform doesn't hold your data hostage — it holds your workflows, your history, and your team's muscle memory. Which is worse. And the only exit is a year-long migration into another platform with the same problem.

Data gravity — flows in, barely escapes
🏢
your org
👥
your staff
🤝
customers
🔧
contractors
your data flows in
⚠ platform
your data · their model · their terms
↓ export.csv (meaning not included)
API access can be revoked. Pricing can change. Migration is your problem.

These aren't software problems you can integration-test your way out of. They're ground state problems. The fundamental layers are missing: a shared representation of what things mean that no platform owns, an audit trail that belongs to every participant equally, identity that travels with you instead of living in someone else's database, and economic commitments that are executable rather than merely promised.

Every integration you build, every audit you reconstruct after the fact, every platform migration you survive — these are symptoms of absent infrastructure. The question isn't which platform to trust. The question is: what does a layer below platforms look like?

The full arc

Voice to economic execution.
Step by step.

A tenant says something. An invoice is anchored on BSV mainnet. Here is every step — with no custom integration code required.
01
Voice · natural language
"The tap in the kitchen is dripping"
Any natural language input — typed, spoken, or sent via message. No structured form. No dropdown. Just the intent.
02
Core · Plexus identity
The right hat is resolved
The tenant is acting under their tenant hat — scoped to read-only status updates and submission. The property manager has a PM hat with dispatch and approval capabilities. Neither can act outside their hat's scope.
tenant hat → capabilities: [submit, status-read]
PM hat → capabilities: [dispatch, approve, full-read]
03
Runtime · intent layer
Intent classified
Embedded into a vector, matched against the taxonomy, confidence computed. The Pask entailments network sharpens the match. Routes to services.trades.plumbing without app-specific classifier code.
taxonomy: services.trades.plumbing · confidence: 0.94
04
Core · semantic objects
A cell is created
The maintenance request becomes a 1024-byte cell — the same format it will have in memory, on the wire, in storage, and on-chain. Genesis hash set. From this moment, every change is chained.
objectKind: maintenance_request · linearity: AFFINE
stateHash_0: SHA-256(genesis) · ownerHat: tenant cert
05
Core · policy engine
Business rules evaluated
The policy is compiled to ANF bytecode and executed in the 2-PDA kernel VM. It checks the PM's hat capability — the rules travel with the cell, not the server.
(check-cap DISPATCH 0x03) → kernel_execute() → { ok: true }
06
Extensions · cross-domain dispatch
Tradie dispatched via hat-scoped envelope
A dispatch envelope is written — one semantic object that both the property and trades domains reference. The PM's hat controls what the tradie can see. The owner's hat gates cost approval. The tenant's hat allows only status reads. Data access is hat access.
appendPatch(db, { kind: "dispatch", delta: { tradieHat, property },
expectedPrevStateHash: stateHash_0 })
07
Core · WASM wallet + BRC-100
Payment authorisation inline
The tradie's invoice is signed with their business hat key. The owner approves with their owner hat. The BRC-100 signed bundle carries the payment authorisation alongside the identity proof — no separate payment flow.
SignedBundle: { IDENTITY_KEY: tradieHat.certId,
SIGNATURE: secp256k1(invoice_hash), payload: invoice_cell }
08
Extensions · chain-broadcast
Cell anchored. Audit trail sealed.
The cell — unchanged from the format it held in memory — is broadcast as a BSV transaction. It lands as a spendable on-chain UTXO: the cell data lives in the locking script, the UTXO exists on-chain until consumed. A BEEF carriage chain carries the SPV proof. The full causal chain from "the tap is dripping" to an on-chain invoice is sealed — and the invoice cell's linearity is now enforced by Bitcoin's double spend protection, not just the policy VM.
The substrate claim

Voice to economic execution.

No data silos. No platform lock-in. No integration tax. Contextual identity that travels with you, an audit trail nobody owns, and economic commitments enforced by consensus — not promised in a PDF.

Get in touch →
What is a substrate?

Not another app.
Not another platform.
The layer below both.

Apps solve problems by adding features. Platforms solve problems by adding APIs. Neither solves the ground state problem — because they are the ground state problem. A substrate is different: it provides primitives that every application is composed from, owned by no platform, available to every participant.
An app

Has features

  • Solves a specific problem
  • Fixed domain logic
  • You configure it
  • Someone else's model
  • Opaque audit trail
A platform

Has APIs

  • General-purpose tooling
  • You integrate into it
  • You still build the semantics
  • Vendor lock-in at the edges
  • Identity bolted on
A substrate

Has primitives

  • Atoms of meaning and economic action
  • Semantics built in, not bolted on
  • Contextual identity from day one
  • Immutable audit trail always
  • Extends without rebuilding core
Every system that solves a real problem ends up reinventing the same three things: understanding what someone means, proving what happened and when, and making economic commitments that can't be repudiated. These aren't features. They're infrastructure — and they belong below the application layer, not inside it. Semantos provides all three as primitives. You bring the domain logic.
The primitives

Four atoms.
Everything else is built on top.

01

The Cell

Every unit of meaning is a 1024-byte cell. It knows its type, its author, its history. It can travel anywhere — browser, server, microcontroller — and be verified on arrival. Memory, runtime, and network all use the same format.

Header · 256 b
Semantic Payload · 768 b
identity · linearity · type · historydomain content
02

Linearity

Values have flow constraints baked in. A payment-channel state can only be consumed once, like cash. A certificate must always be used, never silently dropped. The policy VM enforces this before broadcast — and on-chain, BSV's UTXO double spend protection enforces it at consensus. Two independent guarantors of the same type system.

LINEAR Exactly once — cash, capability, decision DUP✗ DROP✗
AFFINE At most once — draft, transfer record DUP✗ DROP✓
RELEVANT At least once — certificate, schema, fact DUP✓ DROP✗
03

Semantic Objects

Append-only records where every change is a cryptographic patch. Nothing is deleted. Every state is provable. The audit trail is a first-class structure secured by a hash chain — not a logging afterthought.

0x000…genesis{ created: maintenance_request }
0x3f8…{ dispatched: tradie, urgency }
0x9c2…{ completed: invoice }
04

The Policy Engine

Business rules expressed as code, compiled to bytecode, run inside the kernel VM. The rules travel with the data — not with the server. A Lisp surface makes rules readable; ANF normalisation makes them provably correct.

(check-cap ATTEST)
ANF bytecode
{ ok: true }
Rules are data. They travel with the cell, not the server.
The cell

One format.
Everywhere.

Before the standard shipping container, every port had its own crates, pallets, and cranes. The container didn't change what you could ship — it eliminated the translation layer between every mode of transport. The 1024-byte cell does the same for computation.
In memory
header256 b
payload768 b
total1024 b
WASM stack unit
On the wire
header256 b
payload768 b
total1024 b
Network packet
In storage
header256 b
payload768 b
total1024 b
Database row
On-chain
header256 b
payload768 b
total1024 b
On-chain anchor · 1sat
Layer collapse: the memory representation, the runtime representation, the network representation, and the storage representation are all the same 1024 bytes. There is no serialisation step between layers. No ORM. No codec. The cell is the canonical form everywhere.
On-chain anchor
Cells anchor to BSV not as inert OP_RETURN data — but as spendable on-chain UTXOs. The cell data is embedded in the locking script. The output exists on-chain, unspent, until the cell is consumed.
UTXO existence = linearity enforcement
A LINEAR cell cannot be spent twice — not because the policy VM forbids it, but because Bitcoin's double spend protection makes it physically impossible. The UTXO model enforces the type system at the consensus layer.
Linearity is enforced at two independent layers: the substrate's policy VM checks linearity constraints before broadcast; the BSV consensus layer makes violation physically impossible after. A LINEAR cell that reaches the chain exists exactly as long as its UTXO exists — and can be consumed exactly once, by exactly one spender, provably, forever.
Cell chaining
When a payload is larger than 768 bytes, the cell holds a deref pointer to the next cell. Cells chain like carriages — identical format, unlimited length. The same model as a BEEF carriage chain on BSV.
Cell 0 · root
phase0x00
payload768 b
→ derefCell 1
Cell 1 · payload cont.
typeENVELOPE
payload768 b
→ derefCell 2
Cell 2 · BEEF proof
typeBUMP 0x01
payloadMerkle path
deref
Cell N · …
unlimitedscale
Octave memory — 1024-byte cells, all the way up
1 cell
1 KB
single semantic unit
1,000 cells
~1 MB
small document
1M cells
~1 GB
video, dataset
1B cells
~1 TB
full org archive
1T cells
~1 PB
planetary scale
At every scale, the format is identical. Any peer that can read one cell can read a petabyte chain — the protocol doesn't change.
Plexus & Identity

You are not one thing.
Identity is contextual.

You have a business hat. A social hat. A scientist hat. Each is a scoped identity — a child of your root key cert — with its own capabilities, its own domain, its own context. Plexus is the substrate layer that makes this real.
🔑
Root Identity Cert
BRC-52 · secp256k1 · continuity + recovery
🎩 business hat
invoicesign dispatchapprove-cost
🎩 social hat
messagesharepost
🎩 scientist hat
publishattestpeer-review
🎩 employee hat · junior dev
read-onlyown-branchcreate-pr
Contextual
Each hat is a child cert derived from your root key (BRC-42 hierarchical derivation). When you act in a context, you present the hat for that context. Other participants see only what that hat exposes — never your root identity.
Continuity
Hats are deterministic from your root key. They exist on every device without sync. Lose a device — your hats are re-derived. No separate identity database to maintain or backup.
Recoverability
When you issue a hat, you can set a recovery challenge. If the key is lost, the challenge allows the hat to be re-established. Org hats can have multi-sig recovery so no single person holds the keys.
Org chart = hat tree · data access = capabilities
Company Root
all capabilities
CTO hat
deploy · sign release
all repos · budget
Finance hat
invoice · approve
read-ledger
PM hat
dispatch · read-all
create-request
Senior Dev hat
deploy · sign release
all repos · merge
Junior Dev hat
read-only · own branch
create-pr
Contractor hat
scoped repo · read-only
expires: 90 days
Updating the org chart means issuing, revoking, or re-scoping hats — not editing a database or rebuilding an IAM system.
Hat lifecycle is a semantic object. A hat is a BRC-52 certificate — a defined structure of pubkey, parentCertId, childIndex, capabilities, and domain scope. That certificate is carried as the payload of a cell: same 1024-byte format, RELEVANT linearity (a cert must always be presentable, never silently dropped), hash-chained history of every issuance, grant, and revocation. The hat and the cell are distinct — the hat is the identity credential, the cell is the format in which it lives, travels, and is audited. Data access management is not a separate system. It is the same cell model applied to identity.
Every entity type is a hat tree

Hats aren't just for individuals. Every entity that needs to act, delegate authority, receive assets, vote, or be held accountable maps to a hat tree. The root cert is the entity's identity. Every role, every right, every limit is a child hat with scoped capabilities. Constitutions, trust deeds, articles of incorporation — all become executable policy rather than documents people argue about later.

Corporation

Company

Company rootall authority
Directorsign · approve · appoint
Shareholdervote (weighted) · dividend
Secretaryfile · record · certify
Auditorread-all · attest only
Cooperative

Member-Owned Cooperative

Coop rootgoverned by rules
Membervote (1 member = 1 vote)
Boardexecute · sign · manage
Worker-membervote + labour rights
Observerread-all · no vote
Same pattern applies to trusts, estates, DAOs, constitutional bodies — any entity whose authority structure can be expressed as a tree of scoped capabilities.
Governance as typed cells

Governance is not bolted on — it is built into the type system. Proposals, ballots, votes, stakes, and vetoes are all typed cells with linearity constraints. A vote is LINEAR: cast exactly once. A ballot is AFFINE: can be abstained but never duplicated. The kernel enforces these constraints before anything reaches the chain; BSV's double-spend protection enforces them again at consensus. Two independent layers, same guarantee.

Three governance levels — constraints flow down, disputes escalate up
L0 — Platform
The constitution — RELEVANT linearity, always accessible, never silently dropped. Changing these rules requires a formal breaking-change ballot meeting the platform quorum threshold. Governed by the Semantos core team multi-sig hat.
L1 — Author
Declares who can propose patches to a grammar — the author alone, a contributor ballot, or open vote. Also sets trust class, proof requirements, and who holds execution authority over grammar objects.
L2 — Consumer
Per-node binding — AFFINE, one per node. Pins the grammar version the node runs, holds encrypted credentials (never plain text), and can override taxonomy mappings locally without affecting other participants.
Example — cooperative budget approval
01
Board hat submits a RELEVANT proposal cell: "Allocate $40,000 to equipment fund." Phase: DRAFT → OPEN. Proposal cell hash-chained to board's hat cert.
02
Each member hat receives one AFFINE ballot cell. 47 of 60 members cast theirs. 13 are dropped (abstain). No member can cast twice — AFFINE linearity enforced by the kernel before the ballot reaches the chain.
03
Quorum policy evaluates: 47 votes ≥ threshold (50% of eligible = 30). Tally: 39 FOR, 8 AGAINST. Majority met. Proposal cell phase transitions: OPEN → ENACTED. Every vote, every hat, the full audit chain — on record.
04
Treasury cell dispatched — a LINEAR economic cell representing the $40,000 allocation. Anchored on BSV. The decision and the money are bound together in a single hash chain. The audit trail is complete before anyone files a report.
Wallet & Payments

Payments in any browser.
No plugin required.

Two WASM profiles, one substrate. Every message is a signed, payment-capable bundle. Open a tab — you have a wallet.
📇

The Contacts Book is a PKI

Your contacts are their root certs. You establish an ECDH edge between your key and theirs once — a shared secret derived locally, never transmitted. From that point, every message between you is end-to-end signed and verifiable.

A
Alice (PM)
cert: 0x3a8f…b12 · BRC-52
ECDH ✓
B
Bob (Tradie)
cert: 0x7c2e…44a · BRC-52
ECDH ✓
C
Carol (Owner)
cert: 0x1d9b…e83 · BRC-52
pending
💳

Two WASM Profiles

The cell-engine compiles to two WASM profiles optimised for different deployment targets — from a browser tab to a federation node.

29 KB
Embedded — host crypto
Uses the host platform's crypto via WASM imports — no cryptographic primitives compiled in. The host (browser SubtleCrypto, Flutter, ESP32 hardware) provides secp256k1, SHA-256, and RIPEMD-160. Ultra-compact.
Chrome / Safari Flutter mobile ESP32 / IoT Embedded MCU
183 KB
Full — native crypto
Bundles native secp256k1, SHA-256, RIPEMD-160, and SPV verification compiled directly into the WASM binary. No external crypto dependency — runs anywhere a WASM runtime exists.
brain node Federation peer Server-side Full node
🤝

BRC-100 Interoperability

Any system that speaks BRC-100 can verify, sign, and accept payments from a Semantos client — and vice versa. It is an open standard, not a Semantos lock-in. Every message between nodes is a BRC-100 signed bundle: a CBOR payload wrapped in a verifiable envelope.

SignedBundle {
headers: {
IDENTITY_KEY: certId
NONCE: replay protection
TIMESTAMP: when signed
SIGNATURE: secp256k1
}
payload: Uint8Array (CBOR)
}
Any port, any carrier. A BSV wallet, a Semantos node, a third-party service, or a browser tab can all participate in the same economic transaction — because they all agree on BRC-100.
Compatible with
BSV wallets ARC broadcast MAP Protocol BEEF SPV Any BRC-100 peer
The network layer

Cells don't need HTTPS.
They carry their own proof.

HTTPS exists to solve trust, identity, and integrity for inherently untrustworthy payloads. A cell already has all three — so the transport layer can be anything, including the fastest protocols we have.
Traditional HTTPS world
🔒
TLS + CAs — trust delegated to a certificate authority. The payload is naked; the channel is trusted.
🌐
DNS required — you address a server by name, and DNS resolves it. No DNS, no connection.
🔄
TCP with retry — reliable delivery is handled by the transport. Lossy networks require retransmission logic.
🏠
NAT + central relay — true peer-to-peer is impossible without NAT traversal hacks or a relay server.
Cell network
🔑
Cell carries its own auth — BRC-52 cert in the header. No CA. No TLS. Verify the payload, not the channel.
🔗
prevHash chain — each cell carries a hash of the previous state. Gaps in the chain reveal exactly which cells were dropped on a lossy wire.
📡
UDP multicast mesh — fire one broadcast, all peers receive it. Missing cells are detected by prevHash gap; peers request "cells from hash X onward." No TCP retry logic needed.
🌐
BCA → IPv6 address — a Bitcoin Certified Address derived from the secp256k1 key maps to an IPv6 address. True peer-to-peer without NAT, with ECDH encryption from the contacts PKI.
UDP multicast mesh — prevHash gap recovery
Because every cell carries prevStateHash, peers can detect missing cells on arrival — even over UDP. There is no reliable connection to maintain.
cell arrives → check prevHash matches last known state
gap detected → request "cells from hash 0x3f8… onward"
peer responds → targeted backfill, chain intact
BCA + IPv6 true p2p
secp256k1 pubkey
↓ BCA derivation
IPv6 address (128 bit)
↓ ECDH from contacts PKI
encrypted p2p channel
no DNS · no NAT · no CA
Brain node & field apps

One substrate.
Every target from IoT to cloud.

The same cell engine — compiled to two WASM profiles — runs on a $4 microcontroller, a Flutter mobile app, and a federation node. The protocol doesn't change. The deployment does.
🧠
183 KB WASMnative crypto

Brain node

A federation node running the full Semantos stack — cell engine, Pask learning kernel, relay, and NLU pipeline. Acts as a peer, not a server. No central authority. Brain nodes form the backbone of the UDP multicast mesh.

Linux server VPS / cloud Raspberry Pi On-premise
📱
29 KB WASMhost crypto

Flutter / Dart field apps

Cross-platform Flutter apps for iOS, Android, and desktop use the 29 KB embedded WASM with host-provided crypto. The platform's own cryptographic APIs are injected via WASM imports — giving full signing and verification capability in a minimal footprint.

iOS Android macOS / Windows Dart native
🔌
29 KB WASMhost crypto

Embedded targets

IoT devices and microcontrollers use the same 29 KB embedded WASM. Hardware crypto engines (ESP32, STM32, nRF52) provide secp256k1 and SHA-256 via the WASM import interface. A sensor in the field is a first-class Semantos peer — signing its own cells.

ESP32 STM32 nRF52840 Any WASM-capable MCU

Federated by design — no central node

Brain nodes are peers. They relay cells between clients, anchor to BSV, run the Pask learning kernel, and serve as entry points to the mesh — but none of them is authoritative. If a node goes offline, the mesh routes around it. The contacts book PKI means nodes authenticate each other without any central registry. Add a node, and the network grows. Remove one, and nothing breaks.

Adaptive learning

The system learns
about itself.

Semantos includes a deterministic learning kernel — built on Gordon Pask's conversation theory — that runs on cells, not a separate ML pipeline. Every interaction is a cell. Every domain is a namespace. The system builds an entailments network — a live map of what things mean relative to each other — from the cells it processes.
Entailments network — cells under domains
Domain: services.trades.plumbing
Cells observed: maintenance_request, dispatch, invoice, completion
entails → urgency_classification, tradie_matching, cost_approval
Domain: identity.hat.tenant
Cells observed: submit, status-read, payment-auth
entails → capability_boundary, context_scope
Cross-domain entailment
services.trades ⟺ finance.invoice ⟺ identity.hat.owner
System learns: approval gate requires owner hat when cost > threshold
Deterministic kernel
The Pask learning kernel makes no host clock reads and has no external side effects. Given the same sequence of cells, it always produces the same entailments network. Reproducible, auditable, verifiable — just like the cells it learns from.
Smarter intent routing
As the system accumulates cells, the intent classifier gets better at routing novel queries to the right domain. The entailments network acts as a continuously refined semantic map — no retraining cycle, no ML pipeline, just cells.
Self-modelling
The entailments network runs on cells under domains — meaning the system's model of itself is stored using the same substrate it models. The learning state is inspectable, hash-chained, and can be anchored on-chain like any other cell.
Most AI systems treat learning as a separate pipeline that runs offline and produces a model you deploy. Semantos treats learning as a continuous substrate process — every cell that flows through the system contributes to the entailments network. The substrate teaches itself, in the same format it uses for everything else.
Extensible by design

Add a domain.
Don't rebuild the substrate.

The layer model is strict: each tier can only depend on the tiers below it. New domains slot into Extensions — they inherit all primitives, identity, and payments without touching the kernel.
APPS · Tier 3
Standalone Products
What users interact with
Oddjobz (trades)Property ManagementLoom WorkbenchYour vertical here
EXTENSIONS · Tier 2
Domain Algorithms
Where new verticals are added — the extension point
trades / oddjobzproperty dispatchfinance workflowmetering + paymentscalendar + booking+ your domain
RUNTIME · Tier 1
Entry Surfaces
CLI, NLU pipeline, federation, node daemon
shell / REPL / Lispintent / NLUsession-protocol
CORE · Tier 0
Kernel Foundation
Primitives, identity, wallet — you never change this
cell-engine (Zig WASM)semantic-objectsPlexus / hatsWASM walletPask learning kernel

A new vertical takes days, not months.

You write domain logic against the semantic object API and register handlers in the policy engine. The cell format, linearity, hash chain, hat-based identity, WASM wallet, and blockchain anchoring are already there. You don't rewrite the substrate — you extend it.

Cross-chain execution

Chain-agnostic at execution.
BSV-anchored for finality.

Semantos cells can encapsulate state from any blockchain VM. The policy kernel doesn't care which chain holds the assets — it evaluates conditions, dispatches actions, and coordinates execution across chains. BSV is not a limitation on what Semantos can touch. It is the neutral anchor layer that makes cross-chain atomicity possible.
Why BSV as the anchor layer — not ETH, not Solana
Fixed protocol
EVM chains change consensus rules via governance votes. BSV's protocol is locked. There is no EIP that can alter the settlement semantics your cells depend on after you deploy.
SPV resolves the CAP tradeoff
The "pick two" framing of the CAP theorem is a threshold optimisation problem, not a hard constraint. SPV clients with Merkle-proof commitments enable partition-tolerant consistency — cells verify locally without a full node. Economic incentives produce convergent behaviour automatically.
Script is a proof validator
Bitcoin Script is a deterministic finite automaton. A correct EDI message can encode a lie — the protocol cannot prevent it. A correct BSV Script cannot execute if its conditions are not met. This is the difference between a document and a proof. The trilemma framing — security vs. scalability vs. decentralisation — is a category error. These properties exist in different analytical domains and do not trade off. BSV demonstrates they are simultaneously achievable when the protocol is fixed and economic incentives drive topology.
Further reading: Craig Wright — Scripted Supply: EDI and On-Chain Commerce · The Collapse of the Blockchain Trilemma
Participant chains — execution targets
Any chain can participate. Solana, SUI, EVM chains, other UTXO chains — Semantos cells encapsulate their state as payload. The kernel issues signed instructions; the target chain executes them.
VM-agnostic coordination. A cell holding Solana account state and a cell holding SUI object state are both just 1024-byte cells to the policy engine. The kernel evaluates conditions against them using the same policy engine regardless.
State encapsulation. An EVM contract's state, a Solana account balance, a SUI object — all representable as typed semantic payloads inside cells, with linearity enforced at the substrate level rather than by the host chain's VM.
BSV — the finality layer
Neither chain can notarise the other. Solana can't tell SUI "this happened atomically." They're both state machines. You need a third party that both can verify — one with massive throughput, fixed protocol, and cheap immutable writes at scale.
The anchor cell seals atomicity. When cross-chain conditions are met, an anchor cell is written to BSV. That cell is the timestamped, hash-chained, cryptographically verifiable proof that the coordinated action occurred — or did not. This is what makes "atomic" mean something.
BSV as physical layer. TCP/IP doesn't care if you're on fibre or wifi — it depends on some reliable physical layer. Semantos doesn't care which chains you're coordinating — it depends on BSV as the settlement surface that provides finality at the scale the semantic layer requires.
Example — atomic swap: Solana ⟺ SUI, anchored on BSV
participant
Solana
holds asset A
signs release tx
cell state
kernel
Semantos
policy eval
condition check
dispatch
cell state
participant
SUI
holds asset B
signs release tx
anchor
finality layer
BSV
anchor cell
atomicity proof
immutable record

The anchor cell on BSV is what makes "atomic" true. It lands as a spendable on-chain UTXO — not inert data, but a live object whose existence and consumption are governed by Bitcoin's consensus rules. Both chains can independently verify that the swap occurred — or provably did not — by reading the UTXO state. No trusted intermediary. No oracle. The kernel writes the verdict; Bitcoin's double spend protection enforces it.

The substrate claim holds across chains: Semantos doesn't prescribe which chains you use. It prescribes how their state is represented, evaluated, and settled. You could run a Semantos application that never interacts with BSV directly — and the anchor cell that seals your cross-chain operation is just infrastructure running underneath.