Trust technology
Hand over the proof,
keep the score
What a lender needs to know is “does this applicant clear our threshold?” HACS delivers that one fact, and only that, as a zero-knowledge proof. The score, the tier and the secret value (salt) never leave the applicant’s phone.
Score-private pre-screening
4 steps to a decision, without the score
Tier credential
The applicant holds a credit-tier credential, and its Poseidon commitment is anchored. Tiers run 0~4: POOR · BELOW_AVERAGE · FAIR · GOOD · EXCELLENT.
Proof generated on the phone
The phone generates a zero-knowledge proof showing “tier ≥ threshold” (Circom tier_threshold, Groth16 on BN254). About 2 seconds.
Two paths to the lender
Inside the app’s loan application (default threshold FAIR), the server verifies it instantly and pins it to the application; or the lender verifies it directly through the partner API POST /api/v1/fi/proof/verify.
Decision and verification ledger
Every verification call is recorded in a ledger. A proof that does not hold still gets a clear answer (valid=false) and a reason; only an unavailable verifier is reported as an error.
The circuit
Three lines of constraints, 549 gates
The only public inputs are the commitment and the threshold. The tier and the salt enter only as private inputs, so the proof reveals nothing beyond the fact that the threshold is cleared.
// tier_threshold · Circom · Groth16 / BN254 public commitment, threshold private tier, salt tier ∈ {0..4} Poseidon(tier, salt) == commitment tier >= threshold // 549 constraints
Ask only what you need
Proofs that ask only the conditions you need
Identity conditions and lender conditions can both be asked as zero-knowledge proofs. The applicant proves only that a condition is met, without handing over the underlying data.
Score · level · income · repayment history
Income conditions support 6 currencies: KRW · LAK · VND · THB · KGS · USD.
On mainnet
Confirmed on mainnet
| Decision verifications VALID | 120 |
|---|---|
| Forged proofs rejected | 5 / 5 |
| Scenarios for 8 rejection reasons | 135 / 135 passed |
| Same proofs re-verified on-chain | 133 · 100% match |
| Server ledger | 258 entries · 0 errors |
| Total runs (identity 360 + lender 300) | 660 |
|---|---|
| Unexpected results | 0 |
| ZK proof verifications | 580 |
| On-chain Verified events | 170 |
| Circuit keys | PSE Powers of Tau (80 participants) + Xphere block beacon |
Verify without us
You don’t have to trust our server
The same proof can be checked directly against the verifier contract on Xphere mainnet. It is a read-only call, so it needs neither gas nor an account. Credentials are recorded in the trust registry as hashes only, so no personal data goes on-chain.
| Contract (Xphere Mainnet · chain id 20250217) | Address |
|---|---|
| Tier proof verifier (tier-threshold-v1) | 0xc5887371D8A133a4b9F3827cE54558106c933d86 |
| DID registry | 0xB7d5cd01c5bc133E133e23Bed6B6bFe263233936 |
| Trust registry | 0x852688D815410e3FEa015FD3a07028BF6b981d80 |
| Verification record ledger | 0x72F5Dd07f95a73978eD0b6f575f3D815c1880e85 |
Two lines on any web page
Add the verification widget, and visitors prove they meet a condition while the page checks it directly on-chain.
<script src="https://trendy.storydot.kr/sdk/sw-verify.js"></script> <sw-verify request="tier>=2"></sw-verify>
Open standards
Identity built on standards
Consent by default
Without consent, nothing
Denied by default
Queries open only to the lenders, and for the purposes, the applicant has consented to. Consent can be withdrawn at any time.
Per-institution pseudonymous identifiers
Each lender gets a different identifier, so institutions cannot link one person across each other.
Every query is logged
Even denied queries stay in a hash-chained access log that the applicant and supervisors can trace.