- Consent enforcement splits into three questions — who is this person, what did they agree to, and which exact files does that cover.
- Collapsing them into one system produces something that holds identity documents and media in the same place. Separating them means no party holds both.
- PrestoMint keeps a ledger of approved content fingerprints and answers a membership query at publish time. It never receives the content.
- The layers compose, but each stands alone — PrestoMint accepts any trustworthy identity provider, and ProntoID works without it.
A record you can produce is not a gate
Suppose you have solved the evidence problem. Every asset on your platform has a signed release behind it, from a verified person, covering the exact files. You can produce it on request. Good.
Now the publish button gets pressed four hundred times an hour.
At that moment, a well-organised archive of consent records is the wrong shape entirely. Nobody is going to read a release before a listing goes live. What the pipeline needs is not a document but an answer — something a service can ask in milliseconds and act on without exercising judgement. Demonstrable consent is a compliance property. Queryable consent is an engineering one, and it is the gap most consent systems never cross.
That gap is what PrestoMint exists to close, and closing it properly turned out to require splitting the problem into three.
Three questions that should not share a database
The instinct when building this is to make one system that does everything: verifies the person, stores the release, holds the media, and enforces the rules. It is simpler to draw. It is also how you end up operating a single service that holds passport scans and intimate photographs in the same infrastructure, which is a sentence no security review survives.
Splitting by question rather than by convenience gives three layers, each with one job and one thing it deliberately never touches.
Establishes that a real, specific human is present — the same check that powers KYC and age assurance. It hands out a verified-identity reference and nothing more.
Captures the signed release between the two parties and carries revocation. The agreement itself, kept cleanly separate from the identity that signed it.
Mints an approved set of content fingerprints against a verified identity, then answers one question at publish time: is every fingerprint in this piece of content inside an approved manifest?
Read the chips down the right-hand side and the architecture states itself: the identity layer never sees the content, and the ledger never sees the content. Only the platform holds media, and only the identity provider holds identity. No component is in a position to correlate a face with a document with a file.
Five steps, four parties
End to end, the flow looks like this. The important column is the right-hand one — which party is doing the work at each step.
Two details in there carry more weight than their length suggests. At step two, the reviewer sees the content streamed view-only and watermarked from the platform — they are approving what will actually be published, not a description of it, and no copy leaves the platform to make that possible. At step three, approving a subset is allowed. A person can bless eleven frames out of fourteen, and the manifest records eleven.
Images move between exactly two parties: the reviewer looking at them, and the platform that already holds them. Everything crossing any other boundary is a fingerprint, an identity reference, or a yes/no.
That is the whole design, and it is worth stating in its negative form. There is no point in this system at which content and identity documents sit in the same place — which means there is no single breach that exposes both.
What the gate actually looks like
The hot path is one call. The platform computes fingerprints from its own bytes, sends them with the subject reference, and gets back a boolean.
# is this set cleared to publish? { "subject_ref": "pid_2f19c…", # verified identity "fingerprints": [ "sha256:9f4a…b1c7", "sha256:2d80…4e9a" ] } ← response { "authorized": true, "manifest_root": "a77f…03e1", "version": 3, "unmatched": [] }
Note what is absent. No contract text, no scope evaluation, no date arithmetic, no discretion. All of the interpretation happened once, at approval time, when a human was actually looking at the content. What survives into production is a membership test — and unmatched tells you precisely which fingerprints failed, so a partial rejection is actionable rather than mysterious.
Three endpoints carry the lifecycle:
Why revocation gets easier, not harder
Withdrawal is where most consent systems quietly fail. Consent is captured once at upload, and thereafter the asset is simply live — so honouring a withdrawal means finding every place the content ended up and removing it by hand.
A membership gate inverts that. Because the check runs before every publish rather than once at ingest, revocation does not have to chase anything. Remove the fingerprints from the approved set, and the next gate call returns false. Withdrawal propagates by membership: anything no longer inside an approved manifest stops clearing, wherever it sits in the catalogue.
This also handles the case that breaks folder-based systems — content that gets reshuffled, re-listed, bundled or duplicated across products. The fingerprint travels with the bytes, so the authorisation follows the content rather than the filing.
Restraint as an integration strategy
The most interesting design decision here is what PrestoMint refuses to do.
- It does not verify identity. It accepts a verified-identity reference and trusts the provider that issued it. ProntoID is the natural default — same team, aligned contracts — but a platform already running another trustworthy provider can keep it.
- It does not hash the content. The platform computes fingerprints from its own bytes against a shared scheme. The ledger only ever receives the result.
- It does not touch the images. Not stored, not fetched, not seen — which is the property that keeps a ledger from acquiring content-controller obligations it has no business acquiring.
Each of those is a capability the product could plausibly have absorbed, and each would have made it harder to adopt. A ledger that insisted on being your identity provider would be a rip-and-replace decision. One that answers a membership query is a call you add to your publish path.
Two things to think about before you integrate
Some honesty about the edges, because the failure modes here are specific.
- Fingerprints follow bytes, and bytes change. Re-encoding, cropping, resizing or transcoding an approved asset produces different bytes. Your integration needs a deliberate answer to derivatives — whether variants are fingerprinted and minted at approval time, or generated downstream of the gate. This is the single most common thing teams get wrong when adding a hash-based check to an existing media pipeline, and it is worth designing before the first call, not after.
- A fingerprint is a pseudonymous identifier, not anonymous data. Anyone holding the original file can confirm whether it appears in a manifest. That is a feature at the gate, but it means fingerprints and subject references should be handled as personal data in your own records — access-controlled and retention-managed like any other identifier, not treated as inert hashes.
Where this fits
Three shapes of problem map onto this cleanly. Creator and marketplace platforms get a publish gate that survives content being added, removed and reshuffled across listings. Stock and modelling agencies get one review covering a whole shoot distributed across many products, with per-asset granularity and revocation that propagates. AI likeness and consent registries get provable, revocable evidence that an identifiable person agreed to a specific use of their likeness — which is the question regulators are actively working through right now, and one that paper cannot answer at all.
The through-line is the same in all three: a person consented once, to something specific, and the system can prove it mechanically every time thereafter without anyone re-reading anything.