The package
Two products. One boundary that is never crossed.
MBLTS proves what happened to a ballot package. Blindfold answers whether a person is entitled to one. Neither ever learns, encodes, or can be made to reveal how anyone voted — that is an architectural invariant, not a policy setting.
MBLTS · Mail-Ballot Lifecycle Token Service
What ships
- Token issuance. A 256-bit CSPRNG token per authorized mail-ballot package, election- and jurisdiction-scoped, expiration-bounded, one-time for acceptance. Only the SHA-256 digest is retained in the authoritative database; the raw value exists to be printed as a controlled QR/Data Matrix on the outer return envelope.
- Tamper-evident append-only signed event log. Canonical event schema, per-token sequence numbers and hash chaining, Ed25519 event signatures, idempotency keys, and periodic signed Merkle-root anchors with an inclusion-proof API and an independent verifier CLI.
- Intake. Records physical receipt, condition and custody at the intake station. Election-office receipt establishes RECEIVED even when no postal scan exists — a missing USPS scan can never by itself cause a rejection.
- Validation. Jurisdiction-configured envelope validation. Legal timeliness is an authority decision, not an inference from a barcode.
- Cure workflow. CURE_REQUIRED → CURED with deadline clocks configured per election, plus the daily list of missing and inconsistent signatures owed to each qualified political party.
- Auditor portal. Signature and hash verification, Merkle inclusion checks against archived public keys, and reconciliation of token totals against physical inventory and anonymous tabulation batches. Role-limited; no access to selections.
- Voter status channel. Authenticated, minimal, coercion-resistant: authorized administrative status and official next steps only. No raw codes, no custody detail, nothing transferable that could prove a vote.
| State | Meaning |
|---|---|
| ISSUED | Token created and assigned to an authorized package |
| OUTBOUND_IN_TRANSIT | Evidence of outbound movement |
| DELIVERED_TO_VOTER | Postal delivery event; informational, not required |
| RETURN_IN_TRANSIT | Evidence of return movement |
| RECEIVED | Election office has physical possession |
| CURE_REQUIRED | Correctable defect identified under governing rules |
| CURED | Cure submitted and accepted for continued review |
| ACCEPTED | Validation requirements met |
| REJECTED | Not accepted under applicable rules |
| VOIDED / REISSUED | Withdrawn, or replaced by a successor token |
| SPENT | Acceptance plus dual-controlled privacy separation; permanently unusable |
SPENT requires both an accepted package and a dual-controlled PRIVACY_SEPARATION_COMPLETED event. Any attempted use of a terminal-state token produces an exception event, never a new state.
Core guarantees
Unique and unpredictable
Every token is unique, non-predictable, election-scoped and one-time for acceptance, and is never derived from name, address, voter ID, date of birth, party, ballot style or selections.
Every transition authorized
Each authoritative state change is authorized, timestamped, signed and appended. Errors are corrected with compensating events; history is never overwritten.
Postal scans never override law
USPS data may enrich the record but cannot silently override official intake or statutory rules. The election authority makes the controlling decision.
Full reconciliation
Any token can be reconciled from issuance to an allowed final state, and totals reconcile against physical inventory and anonymous tabulation batches.
Unlinkability after separation
Once privacy separation completes, no supported data path joins the voter or token to the anonymized ballot or tabulation record.
Deletion is detectable
An auditor can detect deletion, alteration or unauthorized reordering of events within committed batches, using archived keys and published roots.
Three layers, kept distinct
Postal tracking, election authorization, and audit evidence are separate identifiers with separate purposes. Collapsing them into one globally usable identifier is the failure mode this design exists to prevent.
Layer 01
USPS transport identifier
The serialized Intelligent Mail barcode — a 65-bar USPS barcode used to sort and track letters and flats, and to follow individual ballot mailpieces to and from voters. Used strictly as a postal reference. It is not a secret, not a vote credential, and not proof of legal receipt or acceptance.
Layer 02
Election lifecycle token
An opaque one-time credential bound to the outer return envelope. Never printed on the ballot itself, never carried into the anonymous tabulation environment, independently revocable and reissuable. Associated with an IMb only inside a restricted administrative mapping.
Layer 03
Signed event log
Append-only events with per-token hash chains and periodic signed Merkle-root anchors. Structured after the NIST SP 1500-101 election event-log common data format so events export to a documented, non-proprietary schema. Anchoring is a tamper-evidence mechanism, not a ledger.
Trust boundaries A–D
No API may allow a caller to join Boundary A or B with Boundary C after privacy separation completes. That single rule is what makes the rest of the system safe to deploy.
| Boundary | Domain | Permitted | Prohibited |
|---|---|---|---|
| A | Identity & eligibility | Voter identity and eligibility stay inside the election-management domain | Ballot choices, cast-vote records, tabulation records |
| B | Package lifecycle | Token digests, IMb association, custody and processing status inside the MBLTS domain | Vote choices, cast-vote records, ballot images |
| C | Ballot secrecy | Anonymous ballot and batch data, after controlled dual-control separation | Voter identity, IMb, lifecycle token, envelope ID |
| D | Public reporting | Aggregate, privacy-reviewed statistics | Individual ballot status, identity-to-token mappings |
The voter status channel sits outside all four: it presents minimal authorized status and official next steps after authentication, and is explicitly reviewed for coercion resistance so it cannot become a transferable proof of vote choice.
Non-goals, stated plainly
A procurement officer's first question is what a vendor is quietly claiming. These are the things MBLTS explicitly does not do, taken from the specification rather than from marketing.
It does not replace tabulation
Not tabulation, not results certification, not the voter registration system, and not physical chain-of-custody controls. Seals, inventory, trained staff, witnesses and lawful audits remain required. Paper remains authoritative.
It does not prove how anyone voted
It cannot prove who marked a ballot or how a person voted, and it must never produce a receipt usable for coercion or vote buying. Selections never enter a token, QR code, log, notification or report.
No public blockchain
Merkle anchoring is tamper evidence, not a distributed ledger. No public blockchain is used as the lifecycle record, and no individual token or IMb records are ever published.
No digital dependency for voters
No barcode scan, smartphone, app, broadband, video call, biometric or digital wallet is a prerequisite to casting a valid mail ballot or completing a cure. Every essential path has a non-digital equivalent.
Also excluded by design
Campaigns and other unauthorized parties get no individual ballot-status access. The tabulation system may not query lifecycle or identity data. USPS scan presence is never a prerequisite for counting a physically received lawful ballot. MBLTS is not a claim of EAC or VVSG certification; jurisdiction-specific legal and administrative review is mandatory before use AZ SOS voting equipment.
Blindfold
Privacy-preserving eligibility layer. Held back until the certification question is answered in writing.
Blindfold answers eligibility questions — is this person registered, entitled to this ballot style, and not already credited with a returned ballot — while minimizing the identifying data that has to cross between the registration system and the lifecycle domain. It integrates with the statewide AVID registration platform and county election-management systems, and it requires materially heavier cryptography and a third-party proof audit than MBLTS does.
Unresolved Arizona certification classification
Arizona requires that “all components of a voting system are certified according to state and federal law prior to use”, and vote-recording or tabulating machines may be used only if tested by a laboratory accredited under HAVA, with a three-person Secretary of State committee testing and recommending and the Secretary making final adoption AZ SOS voting equipment A.R.S. §16-442. Neither source defines which components fall inside “voting system”, so whether an eligibility layer is captured is a live legal question. Modifying certified equipment without approval is a class 5 felony under A.R.S. §16-1004(B). The county's 2023 ballot-printer replacement became a public controversy precisely over testing and certification Votebeat, printers.
Consequences if it applies: an added 9–18 months of timeline and a certification-risk reserve of $150,000–$400,000 Modeled. Published lab-testing cost: not available in any source we could locate. Our position is that Blindfold does not get scoped into a Maricopa bid until an Arizona election-law opinion is in hand.
What it adds
- Registration-system integration (AVID / county EMS)
- Cryptographic design review and third-party proof audit
- Eligibility answers with least-disclosure data movement
- Same append-only event and audit envelope as MBLTS
What it does not change
- Boundary A still holds: identity stays in the election-management domain
- It does not become the authoritative registration system
- It does not touch selections, and cannot be made to
- Paper and jurisdictional process remain authoritative
How to read the numbers on this site. Every Maricopa County figure — budgets, ballot volumes, statutory deadlines, vendor unit prices, procurement thresholds — carries an inline link to the primary document it came from and is marked Sourced. Figures describing Operation Encrypt's cost to deliver, pricing, deal sizing and margin are marked Modeled: they are internal planning estimates built on top of sourced compliance, insurance and unit-price anchors, and they are not quotes, offers, or proposals.
Derived values (a sourced numerator divided by a sourced denominator, or two sourced figures summed) are labelled derived and both inputs are linked. Nothing on this site is legal, accounting or procurement advice. The Arizona certification-classification question — whether a given component falls inside the statutory definition of a “voting system” under A.R.S. §16-442 — is unresolved and requires an Arizona election-law opinion before any bid.