Companion piece to the joint TKC, Transformational and ShareRing announcement released 23 April 2026.
For the commercial strategy and what Thailand means for ShareRing’s next chapter, read Rohan’s companion post.
We recently announced the thing we’ve been heads-down on for the best part of a year: a national-scale Verifiable Credential and Digital Document Wallet infrastructure for Thailand, launched jointly with TKC and Transformational. Press releases are necessarily high level, so I want to spend a bit of time here on what’s actually happening under the hood, what’s ours, what’s open standards, and what all of it means for ShareLedger and the SHR holders who’ve stuck with us.
Fair warning, This is a little tech focused. That’s kind of the point.
The problem we keep running into
Thailand has 95 percent internet penetration. And yet in 2026 you still have to take a half-day off work, show up at a counter that closes at 3pm, and hand over a photocopy of your ID and a printout of something that was printed from a PDF that was scanned from an original that nobody can find anymore. That chain of custody is the problem. Once a document is on paper, nobody downstream can actually verify it. That’s how forged affidavits get used to change directorships, how student loans become unrecoverable because the university records don’t talk to the lender, and how entire industries run on the honor system with a side of spot-check.
A digital document wallet fixes this by giving every important document a cryptographically verifiable twin. The holder carries it on their phone. Anyone can check, in seconds, that it really was issued by who it says issued it, that nobody’s tampered with it, and that it hasn’t been revoked since. No phone calls. No emails to the registrar. No wet signatures.
That’s the promise. The rest of this post is about how we actually deliver on it.
The open-standards bits
Four acronyms do a lot of the heavy lifting, and none of them belong to us. This is deliberate. Identity has been burned too many times by proprietary silos, and you can’t build a national trust layer on a walled garden.
Decentralized Identifiers (DIDs). A DID is a globally unique identifier that resolves to a public key, controlled by whoever owns it, anchored on a registry anyone can read. Every issuer in our system (a university, a state-owned enterprise, a bank) has a DID. Every wallet has a DID. The signature on a credential only means something because the verifier can resolve the issuer’s DID and check the key.
Verifiable Credentials (VCs). A VC is a signed JSON document that follows the W3C Verifiable Credentials Data Model. Think of it as the digital equivalent of a stamped, signed piece of paper, except the stamp is a cryptographic signature that can be validated anywhere in the world without phoning home to the issuer.
Self-Sovereign Identity (SSI). The holder holds their own data. The issuer doesn’t keep a copy. The verifier doesn’t build a dossier. When you present a credential, it’s peer to peer, with your explicit consent, disclosing only what the verifier actually needs.
Zero-Knowledge Proofs (ZKPs). This is a crypto favourite, but with little understanding of real world benefits. ZKPs let you prove a statement about your data without handing over the data. Prove you’re over 20 without revealing your date of birth. Prove you hold a valid professional licence without showing the number. Prove a company is in good standing without disclosing its directors. The verifier gets a yes or no. You give up nothing else. I think this is the part of the stack that ages best, because every year regulators get more squeamish about PII sharing and every year ZKP tooling gets more practical.
These four things (DIDs, VCs, SSI, ZKPs) are W3C, DIATF and ISO standards. We don’t own them and we don’t want to. Interoperability is the point.
Alongside those four sits OID4VC (OpenID for Verifiable Credentials), the emerging interoperability layer that defines how credentials are issued and presented across systems using familiar OAuth-style flows. Via our partners at Transformational we’ve been working directly with ETDA on aligning our implementation with the latest OID4VC drafts, because if Thailand’s infrastructure can’t talk to the rest of the world’s wallets and verifiers, we’ve just built a more sophisticated silo. The point of national trust infrastructure is that it has to plug into everyone else’s.
Where ShareRing fits in
Standards compliance is the floor, not the ceiling. Everyone serious in this space is expected to tick those boxes. The interesting question is what we’ve built on top, and this is where I think we have a genuine edge.
A reusable identity that isn’t a honeypot. The incumbent identity providers, the ones you’ve been KYC’d by a hundred times already, run centralised databases full of everyone’s passport scans and selfies. That’s a honeypot. It gets breached, and it does get breached, and when it does your documents end up on a forum somewhere. Self-sovereign identity removes the honeypot by design. Your data lives on your device, encrypted, and never on a central server, including ours. Verify once, reuse anywhere, and nobody builds a profile of you along the way.
Trust stays with the real authority. This is an architectural point that often gets missed, and I think it’s one of the most important. Centralised KYC providers are themselves the issuer. They do the checks, they vouch for the result, and relying parties have to take the provider’s word for it. In our model the actual authority is the issuer. When a Thai university issues a transcript, it’s the university that signs it, and when a graduate presents it, the verifier is trusting the university, not ShareRing. We just run the rails. That’s the way it should be, and it’s how we can onboard any number of third-party issuers (universities, banks, government agencies, professional bodies) without becoming a single point of trust or a bottleneck. A centralised provider can’t really do this. If they let someone else be the issuer, they stop being the product.
The same UX as a centralised KYC flow, without the centralised bit. The hard part of SSI isn’t the cryptography, it’s making it not feel like a crypto wallet. Users don’t want to think about DIDs and key pairs. They want to tap, scan, done. Matching the smoothness of a centralised onboarding flow while actually being decentralised underneath is the product problem most of this industry is still avoiding. We’re not claiming we’re there because we announced it. We’re claiming it because it’s in real app stores and real users are using it.
Backup and restore without a seed phrase. Anyone who’s tried to onboard a non-crypto user knows the twelve-word recovery phrase is where you lose them. So we don’t use one. Lose your phone or switch devices, scan your face, verify, and your identity vault comes back. No paper backup, no “what about my grandma”, no wallet rituals. Decentralised, biometrically recoverable, and genuinely usable.
Privacy by design, not as a feature toggle. No PII on chain, ever. Selective disclosure via ZKP so verifiers only see what they actually need. Consent is explicit, logged on the user’s device, and auditable by the user. We made these architectural calls at the start, because retrofitting privacy is how you end up in the newspaper.
ShareLedger. Our own Layer 1, built on the Cosmos SDK, tuned for identity. We didn’t want to rent space on a general-purpose chain that also has to serve memecoins and NFT drops. Identity transactions have a specific shape (frequent, small, latency-sensitive, privacy-critical), and ShareLedger’s message types, fees and validator set are calibrated for that. Dedicated freight line, not a commuter train with cargo bolted on.
ShareRing Me and ShareRing Link. The consumer wallet and the enterprise SDK. Me is in production on iOS and Android, with real users. Link is how banks, universities and government agencies plug issuance and verification into the systems they already run. When TKC talks about “seamless connectivity via SDKs and APIs” in the release, that’s Link.
Schemas and status infrastructure. Every credential type needs a shared schema and a revocation registry. We publish, version and operate both. Neutral infrastructure, actually operated.
Accreditations that aren’t a slide in the deck. DIATF, ISO 27001:2022, GDPR, PDPA Thailand, Australian Privacy Act. Hard to get. Harder to keep. A lot of projects in this space are running on a compliance slide. We’re running on actual audits.
A real production track record. We’ve been live in multiple markets for years. What’s rolling out in Thailand isn’t a pilot dressed up as a product, it’s the same stack tuned for a new jurisdiction.
One line: we’ve built a reusable, decentralised identity that feels like a centralised one, survives a lost phone without a seed phrase, and never parks your data on a server that could get breached. That, more than the standards compliance, is the part that’s hard to copy.
What actually hits ShareLedger
The architectural rule we never break: personal data never goes on chain. Not encrypted, not hashed-with-a-hint, not anything. If it can be correlated, it stays on the device.
What the chain does store:
- Issuer registrations. The DIDs and public keys of every authorised issuer. This is the anchor that lets any verifier, anywhere, trust a signature.
- Credential schemas. The shape and meaning of each credential type, so everyone interprets the same field the same way.
- Revocation and status lists. Cryptographic accumulators that let a verifier check in a single lookup whether a credential is still valid. The list reveals nothing about who holds what.
- Anchors and proofs. Compact cryptographic commitments against which tamper checks and ZKP verifications run.
Everything else (the credential body, your name, your date of birth, your licence number) lives encrypted on the holder’s device. Lose the phone, the chain is untouched. Audit the chain, there’s nothing personal there to leak. That’s the whole design philosophy in one line.
A credential, cradle to grave
Picture a Thai university issuing a digital transcript in August 2026 (one of the scenarios on the published roadmap).
- Issuer setup. The university’s DID is already registered on ShareLedger. Their registrar signs transcripts with the matching private key. Anyone, forever, can verify that signature against the on-chain record.
- Issuance. The transcript is generated, signed, and an anchor is written to ShareLedger. The credential itself is handed to the graduate’s wallet. This is a chain transaction.
- Presentation. The graduate applies for a job overseas. The employer asks for proof of qualification. The wallet builds a verifiable presentation, optionally using ZKP to disclose only the specific fields the employer needs. Consent is explicit.
- Verification. The employer’s backend resolves the university’s DID on ShareLedger, validates the signature, checks the status list, and returns a green tick in seconds. No email. No courier.
- Revocation. If the university ever needs to pull a credential (issued in error, fraud discovered, whatever), they publish a status update on chain. The next verifier sees it immediately.
Every step that says “on chain” in that list is a ShareLedger transaction. Hold that thought.
Why SHR holders should care
Up to now, ShareLedger activity has been dominated by token transfers, staking, and bridge flow. That’s normal for a young chain, but it’s also the kind of activity that tracks price and speculation more than real usage. The Thailand rollout changes the shape of that activity.
Every issuance, every revocation, every status update, and every anchored presentation is a transaction. These are not speculative transactions. They’re a university issuing diplomas. A bank recording KYC outcomes. A government agency issuing permits. The roadmap we published today has a state-owned enterprise going live in June 2026, universities in August 2026, and active discussions in financial services, hospitality and public administration on top of that. A single university can push hundreds of thousands of credential events per intake cycle once you count transcripts, enrolment letters, and graduation documents. Multiply by the pipeline behind them.
A few practical takeaways for SHR holders:
- Network utility becomes demand-driven. Issuers pay fees to write credential events. That’s recurring, not one-off. It doesn’t care about the market.
- Validator economics strengthen. More transactions means more fee revenue flowing to the people securing the chain. That’s the flywheel we’ve always wanted.
- The ecosystem broadens past crypto-native users. Thai universities and government agencies will be transacting on ShareLedger without ever touching an exchange. The fee and bridge infrastructure sits inside the enterprise integration layer.
- The narrative shifts. We stop being “a blockchain project” and start being “the trust layer under a national document wallet.” That’s a very different conversation with very different people.
What happens next
From a tech standpoint, the infrastructure we announced today is production ready and standards aligned. From here it’s distribution. TKC brings the national infrastructure footprint. Transformational brings the enterprise and government relationships. We bring the wallet, the SDKs and the chain. The SDKs are designed to plug into legacy systems without rip-and-replace, because nobody in government is going to throw out their existing stack to accommodate ours.
For SHR holders, the practical question has moved from “will there be real-world adoption” to “how fast does issuance and verification volume actually ramp.” The first hard data points arrive in June, then August. I’ll share the network-level metrics as each phase goes live, and I’ll try not to sanitise them too much. If issuance ramps slower than we expect, you’ll hear it from me.
Developer portal and credential schemas are being published at schema.sharering.network and status.sharering.network over the coming weeks. If you want the raw technical detail rather than my voice-over, that’s where to look.
Onwards.
Tim Bos
Co-Founder and Co-CEO, ShareRing
