Interception, not logging

The shift came when we stopped thinking of sealing as logging and started thinking of it as stream interception. The sentinel sdk doesn't wait for a response to complete before it starts working. It opens a stream, intercepts the token flow at the edge node closest to the model's datacenter, and begins constructing the sha-3 hash incrementally — token by token, as they arrive. By the time the last token lands, 90% of the seal is already computed.

Removing the database from the hot path

Early versions wrote directly to a postgres instance on every seal. That gave us clean reads but added 60–90ms of write latency on every call. We replaced it with a write-ahead log at the edge — a content-addressed append-only structure that flushes to the merkle ledger asynchronously. The seal commits in memory first. Ledger confirmation happens within 400ms in the background. The caller never waits for it.

The tls problem

The third thing we removed was tls renegotiation on the internal hop between the interception layer and the edge node. We pre-warm persistent connections during the sdk handshake instead. That single change saved 22ms on cold paths.

What's left

After you remove the database, the post-processing model, and the tls overhead, what remains is a tight stream processor running on a v8 isolate with one job: hash this, sign it, queue it. That's where 8ms lives. Not in the code we wrote — in the code we deleted.