Poll manager
Close of polls: scan bag, scan seal, second badge, done.
A checklist of the containers expected at your precinct. Each one turns green as it's sealed. Nothing left unsealed at close.
Chain of custody for election offices
Custody you
can prove.
A tamper-evident record of who held every ballot container, seal, and memory card — where, and when. Fast enough for election night. Verifiable by anyone. It never touches a vote.
- No votes
- No voter data
- No voting equipment
- Works offline
The 86-second explainer
Election night, explained.
From the first seal scan to a verifier anyone can run. Narrated, captioned, and rendered from the same animation you can scrub live.
Made for the phone in your pocket
No scanners to buy. No hardware to charge.
-
Tap to verifyThe phone's built-in NFC reader checks a seal in about a second and binds it to the container. No extra hardware.
-
Find nearby. Never leave a bag behind.A Bluetooth tag inside every case gives hot-and-cold distance. At handoff the carrier taps the tag to arm it, and the phone stays tethered to the case for the whole leg: lose the link for 15 seconds and the phone alarms. A timeout, never signal strength. Location is recorded only during an active leg, and a separation is logged as information, never as proof.
-
Works fully offlineEvery action is signed on the device and queued. No signal needed at the precinct, in the van, or in the vault.
How it works
Election night in 20 seconds.
A tool slower than paper gets bypassed. So the field app is scan-first, one big action per screen, and it never waits on the network.
-
01
Scan the container
Camera, NFC, or a tap on the expected item. Labels come from your badge printer; nothing new to buy.
-
02
Scan the seal. Second person confirms.
Badge tap plus PIN. Both identities land in one signed event — the person who starts a handoff can never also accept it.
-
03
Done. Signed, queued, synced.
Signed on the device, queued in the outbox, countersigned and chained when the signal returns. Nothing is ever lost.
Built for every job on the floor
One fast path per role.
No menus to hunt through at nine o'clock at night. Each person opens the app and sees the one thing they need to do next.
Courier
Hand off: show your code, watch both signatures land.
A signed QR for the whole load. If a bag's tag leaves your phone's reach, the phone alarms — a safeguard, never a judgment.
Receiving desk
Arrival banner → verify seal → store.
A gateway at the door hears the tag before the van parks. The banner opens the receive flow; the two signatures are still required.
Vault clerk
Scan the shelf. Walk the room. Everything accounted for.
Storage scans record exactly where each container sits. Scheduled walk-throughs compare the shelves against what should be there.
Custody manager
Control room: live map, expected vs. stored, exceptions inbox.
Every site on one map, every late run flagged, every exception assigned. Live updates over SignalR, coalesced so it never flickers.
Records officer
Holds, two-person release, verifiable exports.
Place a hold in seconds; releasing one takes a second approver. Export a bundle a court can verify without calling us.
Audit board
Pull list: location, container, seal, re-seal, return.
Two members sign in together and work the state's sample. The system records retrieval and re-sealing — never a count.
Observer
Logistics only. Status by site — never names, never counts.
A credentialed, read-only view of the sites you're assigned to. The same facts the office sees, with nothing personal attached.
Evidence that survives
Change one record and the whole chain shows it.
Every action is a signed, immutable event. Each container's events form a hash chain. Merkle roots are anchored outside our database. And the export can be verified by anyone, offline.
Read how the evidence works Trust Center✍︎
Signed event
ECDSA P-256 on the phone. Non-exportable key, biometric or PIN.
Signed where it happened, by the person who did it
The phone creates a P-256 key inside the Secure Enclave or Android Keystore. The private key cannot be exported or copied, so a valid signature proves which enrolled device, unlocked by that person's face, fingerprint, or PIN, recorded the event.
- What is signed: the container, the action, both people's identities, the device clock with a boot id and monotonic counter, the payload (seal number, location, reason code, photo hash), and the last chain link the device knew about.
- Canonical bytes: the event is serialized with RFC 8785 before hashing, so any implementation in any language reproduces the exact same signed input.
- Why it matters: nobody can manufacture an event after the fact without that device and that person's unlock, and nobody can alter one without breaking the signature.
⛓
Per-container chain
Each event hashes the one before. The server countersigns and assigns order.
Every event names the one before it
When an event arrives, the server verifies the device signature, assigns the next sequence number for that container, and computes a chain hash from the event hash, the sequence, the previous chain hash, and the server time. It then countersigns that binding with its own key.
- Remove, insert, or reorder any event and every later link stops matching.
- Offline collisions are kept, not dropped: if two devices appended at once, both events are accepted and a flag marks the branch for human review.
- Enforced by the store, not just the code: there is no update or delete API for events, and the database identity itself is denied those operations.
△
Merkle tree
Signed tree heads every five minutes. Consistency proofs show nothing changed.
One fingerprint for the whole record, published where we cannot touch it
Every chain hash becomes a leaf. Leaves are hashed in pairs, and the pairs are hashed again, up to a single root that depends on every event beneath it. Every five minutes the server signs a tree head: the root, the tree size, the time, and the previous root.
A proof for any one event is a short list of sibling hashes. Anyone holding the event and its proof can recompute the root themselves and compare it with the published one. If it matches, that event existed, unchanged, when the root was published. A consistency proof does the same between two roots over time: the newer record is the older record plus appended events, with nothing altered or removed.
Why it stands up to scrutiny
- Proven construction. It is the same append-only log design as Certificate Transparency (RFC 6962), the public logs that Chrome and Safari require for every TLS certificate on the web. It has been studied and attacked in the open for more than a decade.
- Fits how courts authenticate electronic records. Federal Rules of Evidence 902(13) and 902(14) let electronic records and copies be authenticated by a qualified person's certification of the process, including comparison of hash values, and many states have adopted equivalents. A Merkle inclusion proof is that comparison with a published, independently held root as the reference.
- No trust in the vendor required. The roots sit in an independent append-only ledger and immutable storage, and the office can publish them itself. An expert witness can verify with the open-source tool or re-implement the arithmetic independently.
- Plain language for the record: "This event existed, unchanged, when this root was published on this date. Here is the arithmetic, and here is where the root was published."
Admissibility is always the court's decision and depends on foundation testimony and state rules. EasyCustody gives counsel the record, the proofs, the published roots, and the tools; it does not give legal advice.
Try to tamper with a chain in the Trust Center →⚓︎
Anchored outside
Confidential Ledger, immutable storage, and a daily root you can publish yourself.
Copies we cannot rewrite
Each signed tree head is written to Azure Confidential Ledger, a permissioned blockchain-based ledger that runs in hardware enclaves and returns a cryptographic receipt for every entry, and to an immutable Blob container with a time-based retention lock in a second region.
- Tenant witness: the Records Officer receives the daily root by email or into storage the office owns, and can post it on the county website. Once a root is public, nobody, including us, can change history without the mismatch being visible.
- What an attacker would need: to forge device signatures, the server countersignature, the chain, the Merkle proofs, and every external copy, all at once and consistently.
- In this demo the anchors are local stand-ins and are labelled "local-stub" so a verifier never mistakes them for Azure receipts.
▣
Export bundle
Events, keys, proofs, anchors, and a human-readable report in one zip.
Everything needed to check the record, in one zip
- manifest.json with the hash of every file and the scope of the export.
- events.jsonl, every event in server order with all signatures and the server countersignature.
- keys/ device credentials and server keys with their validity windows, so each signature can be judged as of its own time.
- proofs/ the signed tree head, an inclusion proof per event, and a consistency proof against the previous head.
- anchors/ ledger and immutable-storage receipts and witness records.
- report.html, a readable timeline for people, and bundle.sig over the manifest.
Scope it by election, container set, or date range. The Records Officer can redact personal fields, and route data stays out unless the office selects it. Printed reports carry a watermark with the user, office, and time.
✓
Open verifier
Runs on a laptop with no network. Two independent implementations must agree.
Trust the math, not the vendor
An open-source command-line tool that runs offline and prints a plain report. It checks the file hashes, that every device credential was signed by the office's certificate authority and valid at signing time, every event hash, every device signature, every chain link and sequence number, every server countersignature, the tree head signature, every inclusion proof, and the anchor receipts.
- Two implementations, one verdict: a .NET verifier and a TypeScript verifier, written separately, must agree on every test bundle.
- Tamper tests that edit, delete, reorder, replay, or forge an event must all fail verification before a release ships.
- In the browser too: the public transparency page lets anyone drop a bundle in; nothing is uploaded.
Boundary
No votes. No voter data. Ever.
EasyCustody records containers, seals, media, locations, and people. It never tabulates, never reads ballots, never sees a voter list, and never connects to voting equipment. Exceptions use neutral reason codes — the product records what happened; humans decide what it means.
Is this blockchain?
Same mathematics. No coins, no tokens, no public network.
Every event is hash-chained to the one before it, and the whole record rolls up into a Merkle tree, the structure blockchains are built from. The signed roots are then written to Azure Confidential Ledger, a permissioned blockchain-based ledger that runs in hardware enclaves and returns a cryptographic receipt for every entry, and to immutable storage the office can hold itself. There is no cryptocurrency, no token, and no public network, and nothing here records a vote. What matters is not the label but the proof: anyone can check the record with the open verifier against a root the office published.
Early voting and drop boxes
Seventeen days. One continuous timeline.
Every site-day is opened against last night's seals, closed with new ones, stored overnight, and reconciled. Anything missing or extra becomes an exception — never a turnout number.
- Not opened
- Open
- Closed
- Stored
- Reconciled
- Exception
Two-personopening and close-out, every day, at every site.
Drop box runswith two-person teams, seal checks, and optional route recording.
Offline firstfor sites with poor connectivity. Syncs when the signal returns.
Hardware you already own
Same tags as EasyAssetTracker. Nothing new to build, buy, or approve.
Container tracking runs on the AirFinder SuperTags and Link Labs cloud that EasyVote already deploys for EasyAssetTracker. One fleet is shared across EasyInventory, EasyAssetTracker, and EasyCustody, so IT sees the hardware it already approved and the office pays for one pool of tags.
Same tags, same cloud
AirFinder SuperTag: Bluetooth, Wi‑Fi, GPS, and cellular in one tag with years of battery life. EasyCustody reads the office's existing EasyAssetTracker account over Link Labs' API or webhooks. No custom radios, gateways, or firmware from us.
Attach at handoff, remove on delivery
The courier drops a tag in the first bag and scans its label; the receive and store flows prompt its removal the moment the container is on the shelf. Attach and remove are signed custody events, so the record shows who did both.
Route, geofence, shock and tamper
Live fixes on the control room map, geofence alerts when a bag leaves a precinct or reaches HQ, shock and tamper sensing from the tag. All informational: the seal scan on receipt is still the proof, and fixes never enter the chain.
Azure reference architecture
One door in. Every store private. Every event written once.
Clients reach only Front Door. API Management is the single gate to private services. Custody data is append-only — enforced by the platform, not only by code.
ClientsWeb console
ClientsField app · iOS / Android
ClientsOpen verifier
EdgeAzure Front Door Premium + WAF
GatewayAPI ManagementJWT validation · scopes · rate limits · schema validation
Container AppsIdentity serviceOIDC + PKCE · TOTP MFA
Container AppsCustody · Audit · Admin APIs.NET 10 · one write path: append a signed event
Container AppsWorkersprojections · Merkle anchoring · exports
Cosmos DBappend-only events
Key Vault HSMsigning keys
Confidential Ledgeranchored roots
SignalRlive console
Blob · immutablephotos · bundles
Service Busworkers
Local demo
This demo runs the whole thing on one laptop; every Azure service has a local stand-in behind the same interface. Cosmos DB → SQLite with append-only triggers · Key Vault → local keys · Confidential Ledger → an append-only ledger file · Azure SignalR → self-hosted SignalR · Blob → a folder. The signatures, chains, Merkle proofs, and verifier are the real thing.
Try it now
It's running on this laptop.
Sign in as any role, play the election-night simulation, and watch the control room light up. Then export a bundle and verify it yourself.
- WCAG 2.2 AAdesign target, keyboard operable, screen-reader tested
- SOC 2 pathNIST 800-53 Moderate alignment, GovRAMP readiness
- No tabulationnot a voting system, never connected to one
- Open verifierverify any export without trusting EasyVote