# settle: the settlement kernel in portable C

The keystone loop as code that runs on a microcontroller and on a host: canonicalize a question, hash its key,
look it up, verify, decide with compiled rules, record with a validity window, and emit an OER/2 receipt
(draft 0.1 as profiled by [`extensions/oer-receipts.md`](../../extensions/oer-receipts.md)): canonical bytes in the envelope's fixed order, SHA-256 receipt id and chain hash, Ed25519 signature.

Files: `settle.c/.h` (the kernel), `sha256.c/.h`, `tweetnacl.c/.h` (public domain Ed25519), `host_main.c`
(host harness with a modelled meter), `zephyr/` (application skeleton for a Zephyr board; untested build).

Build and cross-verify against the Python reference verifier from the OER/2 vector set:

    make
    ./settle_host firmware_vectors.json 400
    python3 ../oer2_verify.py firmware_vectors.json          # PASS v10 firmware chain from the C kernel
    cmp firmware_vectors.json ../firmware_vectors.json       # the pinned corpus: no drift

The harness writes 400 receipts, the records they cite and a ledger identity; the verifier checks canonical
bytes, ids, chain, sums, floors, records and signatures. Two implementations, one receipt — three with `wai_oer_vectors` in `wai-rs`, which CI runs over this output.

What the kernel does not do yet: escalate new questions upstream (a callback hook is the next addition),
read a rail meter (the host models one; the Zephyr skeleton counts cycles), and hold the signing seed in a
secure element. Energy constants inside the kernel (cycle energy, bits committed) are the model's projected
values until the bench node measures them.