The approval call
Cryptocurrencies Demo with LiveKit and Voice AI: proof of concept. Jeff Lawson
A spoken confirmation, 57 seconds, with sound. On a live approval call the reader says a 6 ETH transfer back; the approver on the Android tablet says "Confirm, six ether." and the reader answers "Confirmed for Android." within a second. Both approvers then approve; Ethereum confirms the transfer.
What it is
CryptoDemo is a working proof of concept of a bank's shared platform for digital assets on Ethereum, Solana and Canton. Every transfer needs two approvals from two different enrolled devices; an isolated signing service then signs it in hardware.
Above a set amount (5 ETH, 5 SOL or 500 Canton units) a transfer is approved on a live call that only enrolled devices can join. The call runs on LiveKit, encrypted end to end under the call's own key. A witness on a separate machine gives each approver a challenge on the call, certifies their attendance with a key in its TPM 2.0 and records the call.
A voice joins the call too. It reads the transfer back and listens for each approver to confirm it by saying the amount. Deepgram turns speech into words, Claude Haiku reads what the words alone do not settle and Cartesia speaks. A spoken confirmation is advisory: it goes into the hash-chained history; signing never waits for it.
How the call uses LiveKit and the AI services
Who joins each call, what each line carries and who can hear the audio. Open the diagram full size.
Found on the devices
All three came from the office run on the iPad, the Android tablet and the Mac, not from a test.
The reader went deaf
An approver who joined with the microphone closed was never heard: Deepgram ends a live stream after 10 seconds without audio. The reader keeps every approver's stream open with a keep-alive every 3 seconds and listens again when a new track arrives, so a microphone that comes on late is heard.
Two devices in one room howled
Each device played the call; the other's microphone picked it up and the sound went round. Each device has a switch that silences the call on that device alone. Silencing the incoming track did not hold: LiveKit's Flutter SDK announces a track before it starts it, then enables it as it starts. The switch therefore acts on the track's publication, a subscription setting the media server keeps.
The reader could confirm itself
In that same loop the reader's own voice reaches an approver's microphone. Its line "To confirm, say confirm and the amount: six ether." would then have counted as that approver's confirmation. The reader recognises its own lines (even as speech recognition mishears them) and never counts them.
972 ms at the median from the last sound of "Confirm, six ether." to the first sound of the reader's answer, heard by a listener on the Mac over twenty turns; within a second on the devices in the office.
Decisions
- The reader is Rust on LiveKit's Rust SDK. LiveKit's own Agents framework, in Python, was the quicker route. The reader was built as a Rust Hexagonal Architecture like every other program in the PoC, so the rules it decides by are tested with no call, no network and no service.
- Signalling travels inside QUIC. The media server's signalling port listens on the Mac's loopback only; each party's signalling is carried inside its own QUIC connection to the platform, under mutual TLS with keys in hardware.
- The media server cannot hear the call. Every party joins with frame encryption on. The platform makes each call's key, so whoever holds the platform could listen; a key made by the witness instead is named as further work.
- The read-back is advisory. Requiring it would mean the reader signing each confirmation with a hardware key and the signing service checking it: named as further work.
- The speech services are in the cloud. Deepgram, Anthropic and Cartesia hear or read what they are sent. Their API keys are secrets in software, held in the reader's memory and read at start from the Mac's login keychain: labelled exceptions, as the media server's room-pass secret is.
What it does not show
- A person behind each approval: an attendance proves that the approver's own device answered the witness's challenge on the call, not that a person was listening.
- Who is speaking: a voice is not an identity; whoever is at an approver's device can speak for it.
- More than one reader, more than one language: English only, one reader for each call.
- The call on the iPhone, Linux or Windows: the apps run there; the call runs on the Mac, the iPad and the Android tablet.
- A phone call back to the customer before the approvers approve: named, not built.
- Real money: test ledgers on the PoC's own machines.
The whole video
Seven minutes, captioned, without sound: a transfer approved on a call from the Android tablet and the Mac, then the architecture.
Specified and built
Built with Claude Code to Jeff Lawson's specification and rules: each plan approved before any code, each decision and review recorded as the work went, every rule's test seen to fail with a planted fault before it counted.
162 Rust tests for the platform, the signing service and the CA; 85 for the call, with 12 more against a real media server and the three speech and language services; 39 in the apps. Run in the office on a Mac, an iPad, an Android tablet and an Ubuntu machine whose keys are in its TPM 2.0.
The source code is available to review on request.