Lindblad Protocol Documentation

Lindblad Protocol is an open protocol with physics-enforced hardware security. This documentation covers the public components — smart contracts, API reference, protocol specification, and user guides.

All source code, contracts, and specifications are available on GitHub at github.com/lindblad-protocol.

Lindblad Protocol publishes its core components openly. Everything needed to integrate, audit, or build on top of the protocol is available on GitHub.

All contracts are verified and auditable on-chain. Source code available at github.com/lindblad-protocol/contracts.

Bridge contracts accept USDT/USDC deposits on Arbitrum One and Polygon, verify P-256 ECDSA signatures from certified hardware nodes, and release funds on withdrawal. PYCO is the native token of the entire network regardless of which chain the deposit originates from. Exit fees are 0.1% in PYCO — 50% burned, 50% distributed to node operators.

M2MEscrow is the smart contract enforcing the M2M Commerce lifecycle (request → accept → attest → settle) on Arbitrum Sepolia. The same logic is mirrored on Robinhood Chain Testnet. See the M2M Commerce Model section for the full architecture.

LCP is a four-layer hardware protocol that simultaneously proves the identity, time, and location of every cryptographic signing event. Full mathematical specification at github.com/lindblad-protocol/spec.

The Spectral Ledger is the universal token transport layer of the Lindblad network. Internal transfers between LD addresses are instant and free. Bridge exits to Arbitrum require hardware signing and incur the 0.1% PYCO fee.

Every participant on the Spectral Ledger is identified by their LDXXXXXXX address — derived from the hardware PUF fingerprint of their device.

RWAFi (Real-World Asset Finance) is the architectural pattern enabled by the Lindblad stack: physical attestation, native token minting, and AMM markets unified in a single layer with end-to-end cryptographic verification.

The pattern consists of three sequential primitives, each backed by the same Lindblad Cryptography Protocol:

1. Attest

A physical hardware node measures a real-world value (energy generation, sensor reading, extraction volume) and signs it using its silicon-derived private key. The signature includes a Chua HSC nonce — a non-replayable timestamp from chaotic electrical noise. Verifiable independently via /verify-l2/{signId}.

2. Mint

Once an attestation is recorded, the producer decides what percentage of the attested quantity becomes a liquid token (e.g., 75% of 72,000 kWh → 54,000 GREENKWH tokens). The remainder is registered as physical-use (sold via grid / PPA / self-consumption). Tokens are native to the Spectral Ledger — no bridge required.

The mint percentage can be increased later via recalibration, but never decreased (already-minted tokens cannot be retracted, as downstream holders own a claim).

3. Trade

Minted RWAFi tokens become tradable on LindFi pools paired with stablecoins (e.g., GREENKWH/USDT). The pool establishes a market price through standard constant-product AMM mechanics. External arbitrage anchors the price to real-world markets for the underlying asset (electricity wholesale, commodity spot, etc.).

Pool Categories

LindFi distinguishes two categories of pools, detected automatically from the tokens involved:

The current set of RWAFi-native tokens is small but extensible. Adding a new vertical (lithium, carbon credits, agricultural commodities) requires registering its token name in the attestation pipeline.

Live closed-loop example available at /oracle — real attestation, mint, and market data refreshing every 30 seconds.

M2M Commerce (Machine-to-Machine Commerce) is the second application built on the Lindblad protocol. Two autonomous machines, each with a hardware-attested Lindblad identity, can negotiate a service, deliver it, and settle payment — without any human intermediary or third-party custodian.

The pattern relies on the same foundation as RWAFi: silicon-derived identity (PUF), cryptographic signing (ECDSA P-256), and on-chain verification. The difference is that here the asset being transacted is a service, not a measurement.

Lifecycle

Each M2M transaction passes through five states managed by the M2MEscrow smart contract:

Identity

Both client and provider machines must hold a Lindblad node whose Ethereum address has been registered in M2MEscrow.isNodeRegistered(). The address is derived from the node's public key (keccak256(pubKey[1:])[-20:]) — itself derived from the silicon PUF in real time via BCH(255,139,t=15) fuzzy extractor. The key exists only inside that exact piece of silicon, recovered when needed, never stored.

Settlement

When the provider attests sufficient delivery (configurable threshold), the contract automatically releases the escrowed payment. Partial delivery results in proportional payment plus refund of the remainder. Deadline enforcement ensures stuck transactions can be resolved by either party.

Use Cases

Any service where a measurable unit of work is delivered between autonomous systems:

• Energy — autonomous EV charging at a hardware-attested station
• Compute — edge nodes selling CPU/GPU cycles by the second
• Data — IoT sensors selling data feeds with cryptographic provenance
• Bandwidth — mesh network nodes selling traffic relay
• Storage — distributed storage with hardware-attested data integrity

Deployments

M2MEscrow is currently deployed on:

• Arbitrum Sepolia — primary testnet, contract verified on Arbiscan
• Robinhood Chain Testnet — mirror deployment for cross-chain validation

Live demos: /m2m (educational walkthrough with real on-chain links) and /m2m-live (live hardware verification with a connected Lindblad node).

Base URL: https://lindblad.io — all endpoints are public, no authentication required.

Every PUF-signed operation in Lindblad — pool swaps, liquidity changes, oracle attestations — is mathematically verifiable by anyone, anywhere, without trusting Lindblad. The protocol exposes public endpoints so that any third party can independently confirm a signature was generated by a specific physical node.

This works because Lindblad uses standard ECDSA P-256 signatures backed by silicon-derived private keys. The public keys are public by design — the security comes from the fact that the corresponding private keys live only inside the SRAM PUF of each chip and never leave the hardware.

The Message Contract

When a node signs a challenge, the firmware constructs the message as:

msg = challenge + NODE_ID + str(ts) + chuaNonce_HEX_UPPERCASE
hash = SHA-256(msg)
(r, s) = ECDSA_P256_sign(hash, private_key)

The chuaNonce comes from the Chua HSC chaotic circuit (real electrical noise), making the signature unrepeatable even by the same hardware. The private key is derived from the SRAM PUF via a BCH(255,139,t=15) fuzzy extractor at boot and never persists to flash.

Verify Independently in Python

You don't need Lindblad's code. Any standard cryptography library on any platform works. Example with Python's cryptography package:

# pip install cryptography requests
import hashlib, requests
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.asymmetric.utils import encode_dss_signature
from cryptography.hazmat.primitives import hashes

SIGN_ID = "0e8029bb"
NODE_ID = "LD95A821D"

# 1. Fetch signature data (public endpoint)
sign = requests.get(f"https://lindblad.io/get-sign?signId={SIGN_ID}").json()

# 2. Fetch the node's public key (public endpoint)
key = requests.get(f"https://lindblad.io/node-keys/{NODE_ID}").json()

# 3. Reconstruct the exact message the firmware signed
msg = sign["challenge"] + NODE_ID + str(sign["ts"]) + sign["chuaNonce"].upper()

# 4. Verify with standard ECDSA-P256
pub = ec.EllipticCurvePublicKey.from_encoded_point(
    ec.SECP256R1(), bytes.fromhex(key["public_key"]))
sig = encode_dss_signature(int(sign["r"], 16), int(sign["s"], 16))

pub.verify(sig, msg.encode(), ec.ECDSA(hashes.SHA256()))
print("✅ Signature valid — provably signed by", NODE_ID)

If anything has been tampered with — the value, the timestamp, the device identity — pub.verify() raises InvalidSignature. The check passes only if the signature was actually generated by the private key inside the physical chip whose public key is published at /node-keys/{nodeId}.

Equivalent verification can be implemented in JavaScript (using @noble/curves or Web Crypto API), Go (crypto/ecdsa), Rust (p256 crate), or OpenSSL CLI. The signature format and message contract are identical across all clients.

Endpoints for attesting real-world energy generation and minting native GREENKWH tokens. The workflow:

1. GET /attestations/energy/quote — fetches latest renewable generation from EIA and creates a pending sign request
2. The hardware node detects the pending sign, signs the challenge with its PUF-derived key
3. POST /attestations/energy/submit — finalizes the attestation and mints GREENKWH tokens to the producer

AMM endpoints for liquidity pools. Pools are constant-product (x·y=k) with configurable fees in basis points. All operations that change reserves (add, remove, swap) require a PUF-signed authorization from a hardware node.

Pools are automatically categorized as defi or rwafi based on the tokens involved. See the RWAFi Model section for details.

Endpoints served directly by Lindblad hardware nodes (e.g., Heltec V3 running the Lindblad firmware). These run locally on the device's HTTP server, typically over the LAN at http://<node-ip>. The node's IP appears on the LCD display at boot. All cryptographic operations are performed inside the node — keys are derived from PUF in real time and never leave the silicon.

The M2MEscrow contract enforces the M2M Commerce lifecycle on EVM-compatible chains. Currently deployed on Arbitrum Sepolia (0xdeaED8e809733667D80a8E6ca40A02366598CA60) and mirrored on Robinhood Chain Testnet. Source code is verified on Arbiscan and available on GitHub.

Only addresses registered as Lindblad nodes (via isNodeRegistered) can request, accept, or attest. The registry is controlled by the Lindblad Oracle for the duration of the testnet phase. Future iterations will use on-chain PUF signature verification for fully permissionless registration.

LindWallet runs at lindblad.io/wallet. No installation required. Your device key is generated from your hardware fingerprint on first visit and stored locally.

Deposit USDT or USDC: Connect MetaMask → Bridge tab → select token → enter amount → Deposit. Funds appear on the Spectral Ledger within 30 seconds.

Send internally: Send tab → enter destination LDXXXXXXX → enter amount → confirm. Instant and free.

Withdraw to Arbitrum or Polygon: Bridge tab → Withdraw → select network → select signer → enter destination → Withdraw. Hardware signs the transaction. 0.1% PYCO fee applies.

Connect a node: My Accounts → + → enter node LDXXXXXXX → enter pairing code → Pair. Pairing code is generated by the node and valid for 5 minutes.

Step 1 — Power on: Connect your Lindblad node to power. The hardware boots and generates its unique LDXXXXXXX address from the silicon PUF.

Step 2 — WiFi setup: Connect your phone to "Lindblad-Setup". A captive portal opens — enter your home WiFi credentials. The node joins your network automatically.

Step 3 — Pair with LindWallet: My Accounts → + → enter the node LDXXXXXXX → enter the 6-character pairing code from the node → Pair.

Step 4 — Mining starts: The node begins submitting blocks every ~30 seconds and accumulates PYCO weighted by its Physical Coherence Score. Monitor at lindblad.io/nodes.

Deposit: Approve USDT/USDC → call deposit() on the bridge contract (Arbitrum One or Polygon) → VPS detects the on-chain event → credits your LD address on the Spectral Ledger.

Withdrawal: Request withdrawal → select target network (Arbitrum One or Polygon) → VPS creates signing challenge → your hardware node signs with PUF+ECDSA → VPS submits to contract → tokens released to your address.

Fee: 0.1% of withdrawal amount in PYCO. 50% burned permanently. 50% to active nodes weighted by CV Score.