A Soroban integration that verifies document conditions without disclosing unnecessary data.
An age threshold, an allowed document country, or a supported list check.
A pinned Soroban verifier checks the ZKPassport proof.
The application uses the accepted condition in its access or transaction rules.
Current application: a Testnet anchor. Sybil and multi-proof scenarios require further development.
Example: rejecting an underage applicant only after a lengthy document flow.
Unnecessary billable verifications can consume the operating budget.
Users upload documents and complete the steps, only to learn they are ineligible.
Excess document data may be collected even from applicants who never become customers.
Savings are a hypothesis. We do not assume every failed check is billed or every institution stores documents.
Define the condition, application scope, and validity.
The user generates a proof for a supported document.
Check the proof and the expected policy.
Use the result in access or transaction rules.
In the new SEP example, eligibility is time-limited and account/policy-bound. A proof alone does not authorize token spending.
We make cryptographic verification usable in Stellar application flows.
Trion Labs
Trion Labs
Verifier adaptation · policy checks · Soroban contracts · application integration
Source foundations and modifications are documented in the appendix; attribution does not imply an audit or partnership.
No need to disclose it for this condition.
Prove that the age threshold is met.
These are two separate document attributes.
Check the required set-membership condition.
ZK verifies a selected condition without sharing the source data.
Nationality is not residence. A public policy allowing only one country makes that attribute inferable from a successful result.
Flag reuse without publishing
the document number.
campaign-01 / n:7c…2aProposed uses: rewards, loyalty, and participant distributions.
Campaign deduplication is not yet integrated. Distinguishing one document does not guarantee “one person = one account.”
Exact matching of normalized data against a pinned list.
A separate backend pre-check against digital addresses on the official list.
No match ≠ full sanctions compliance. List freshness, identity matching, and scope require separate assessment.
Example: a payment claim by a participant accepted into a program.
Is the required age or
document-country condition met?
Has a trusted institution approved
this application or payment entitlement?
The application requires all necessary proofs to be satisfied together.
Not yet integrated. Source trust, same-person binding, and reuse rules must be established separately.
A supported prerequisite,
such as age or document country.
Continue with required KYC and other checks.
End the application according to the product rule.
Route to an alternative verification path.
Cost and user-experience benefits will be measured in a pilot, including ZK operating costs and user drop-off.
Keep document fields that the selected check does not need private.
Adapt supported verifier and policy components to the application flow.
Use document conditions for access, pre-checks, or payments.
Build modules for repeat campaign claims and additional participation conditions.
Reuse is a product goal. We do not claim a ready-made universal SDK or measured customer savings.
The wallet opens the anchor’s hosted flow. Soroban verifies the document conditions.
No new phone proof for every exchange within the same valid wallet/policy scope.
The wallet signs the payment separately. The operator observes it and funds the vault.
SEP-24 hosts the interaction; it is not a KYC algorithm. Current public proof/deposits are recorded; public withdrawal and third-party-wallet acceptance remain to verify.
Upstream foundation: mock TRY/USDC rails, SEP-1, SEP-10, SEP-6, simulated SEP-12 KYC,
SEP-38 quotes and payment observation.
Pinned BB5 proofs on Soroban, including both required pairing checks.
Age, nationality, issuer, sanctions root, trusted roots, freshness and scope.
Exact amounts, eligibility, receipts, payout authorization and permitted refunds.
Authenticated, anchor-hosted quote and ZKPassport QR experience.
A wallet/policy grant serves multiple orders until its original expiry.
Ordinary payment observation, saved transaction hashes and reconciliation.
Freighter, Testnet setup, trustlines, explorer links, Railway hosting and CI.
Separate backend OFAC wallet-address precheck ≠ private sanctions predicate. Verifier foundation: Nethermind; ZKPassport circuits and UltraHonk are upstream work.
Wallet control
Firm quote
Native ZK operations
Token contract
The anchor example also includes SEP-1 discovery, a hosted SEP-24 flow, and a SEP-6 exchange API.
The SEP components belong to the anchor example. Other applications can use the supported verifier and policy layer separately.
Component view of the current SEP anchor. Backend payment observation and mock-bank receipts remain separate trust boundaries; the next slide shows the proof sequence.
Current SEP flow: a wallet/policy grant is reusable until expiry. It is not a payment authorization; every order keeps its own exact terms.
The second deposit reused the existing eligibility grant; it was not a new phone-proof run.
Finish the hosted withdrawal flow, unmodified-wallet exchanges and separately admitted judge access.
Independent review, current-list / real-document support, then scoped Sybil and multi-proof modules.
Dated source: handoff 8db2c48 / application f1347f4. Synthetic documents, simulated TRY and mock Testnet USDC. No audit or production-compliance claim.
Use proofs of document conditions
in application rules.
First example: an anchor.
Expansion: access, reuse, and entitlement checks.
| Capability | Documented status | Scope in this presentation |
|---|---|---|
| Age + two country conditions | Current Count8: fresh public proof + deposit | Synthetic age, nationality and issuer conditions; not real identity. |
| Private sanctions list | Included in the recorded public Count8 proof | January 2026 snapshot; not current production compliance. |
| OFAC digital address screening | Separate backend pre-check | Not ZK; not full sanctions compliance |
| Time-limited eligibility | Reusable account/policy grant | Second public deposit reused eligibility; original expiry is unchanged. |
| Sybil / campaign uniqueness | Future design in this presentation | Requires a scoped nullifier registry and identity model |
| Multiple proofs with email | Not yet integrated | Source trust and same-subject binding must be established |
Handoff 8db2c48. Public withdrawal and unmodified-wallet acceptance remain unverified; source records were not rerun here.
Define multiple-document, renewal, and person-document binding rules.
Scope the nullifier to the campaign and entitlement type.
Persist successful claims and protect against reuse.
Assess whether the identity marker can be tracked across programs.
Order replay protection does not replace campaign-level Sybil resistance.
Record the list’s source, version, and date. A pinned root is not a current list.
Exact address matching differs from name/identity screening. Exact matching alone cannot establish a broader result.
Separate proof validity from list freshness. A valid proof does not update an old dataset.
“No match under this list and rule” ≠ “compliant with all sanctions.”
This prototype’s list check is not real-person verification or current production compliance approval.
Wallet-signed prove_order.
Accepted proof escrows withdrawal tokens.
Two-way synthetic acceptance recorded.
No cancellation or refund path.
Hosted proof; ordinary payment + memo.
Operator-attributed custody → vault.
Fresh proof + two deposits recorded.
Limited recovery before payout authorization.
A public withdrawal and exchanges through an unmodified third-party wallet are still to verify. Native proof validity, wallet compatibility and custody are separate questions.
Successful-verification billing and monthly minimums apply.
Measure eligible-user drop-off and alternative-path use separately.
Do not equate an age-condition proof with a full KYC package.
Prices and contract terms may change. Savings and user conversion have not yet been measured in this project.
First deposit: 100.00 simulated TRY → 2.0947892 mock USDC.
| FLOW | ACTION | LEDGER | TESTNET TRANSACTION |
|---|---|---|---|
| Eligibility | Fresh Count8 phone proof | 4,772,528 | 08c7c414b67828…3a1e816e ↗ |
| Deposit 1 | Settlement | 4,772,533 | 14d7463f6cf8b1…4c2553f1 ↗ |
| Deposit 2 | Creation · existing grant | 4,772,819 | 09f9720b7bc73e…c374340e ↗ |
| Deposit 2 | Simulated TRY receipt | 4,772,823 | 557e9d617d4521…bc52db3b ↗ |
| Deposit 2 | Settlement · reused grant | 4,772,824 | fd1b82745299a8…b350daa4 ↗ |
The second deposit reused the existing grant; it is not a second fresh phone-proof result.
Documented in the 20 September handoff, not independently rerun here. Public withdrawal and unmodified third-party-wallet exchanges remain to verify.
| Direction | Action | Ledger | Testnet transaction |
|---|---|---|---|
| Deposit | Proof | 4,767,724 | 4a0e7e262c8422…26710d4e ↗ |
| Deposit | Receipt | 4,767,762 | 08c7206344b357…b692ee6f ↗ |
| Deposit | Settlement | 4,767,765 | b298032e175360…90d9a41e ↗ |
| Withdrawal | Creation | 4,767,774 | b32540361d119c…fcf269e4 ↗ |
| Withdrawal | Proof + escrow | 4,767,860 | c53b5d37fcb830…52b7b499 ↗ |
| Withdrawal | Payout authorization | 4,767,870 | 12e60e19a40bd5…75bc0f98 ↗ |
| Withdrawal | Paid receipt | 4,767,873 | 3edc7e13ee419f…f8dffcfc ↗ |
| Withdrawal | Settlement | 4,767,875 | 51ffbb7c5f2077…b45250b1 ↗ |
These hashes do not belong to the new SEP/Outer8 deployment. The new deployment needs separate acceptance tests.
Kaan’s TR Mock Anchor, ZKPassport proofs, and open-source verifier foundations.
Supported profile adaptations, native verification, policy checks, and Stellar application integration.
Handoff: 8db2c48.
Earlier transaction evidence: 389ed8c.
Self: reference for the problem framing.
Single HTML file · embedded organizer logo · inline SVG icons · no external fonts or libraries.