A short, friendly reference for every term and idea ADULIX is built on: who it's for, how the trust record actually works, and why it leans on established standards instead of inventing its own. Written for anyone curious, not just developers.
Core concepts
Micro, small, and medium enterprise: the small traders, exporters, and family businesses that make up most of the informal economy. ADULIX gives each one a single, portable trust record.
Shared digital rails, like identity systems or payment networks, that anyone can build on without asking permission from whoever built them. ADULIX aims to be DPI for business trust, the way a national ID program is DPI for identity.
A single, shared, append-only record of every fact ADULIX knows: registrations, verifications, consent decisions, and issued credentials. Nothing is ever edited or deleted, only added.
An MSME decides who (the grantee) can see how much (the scope) of its data, and can revoke that decision at any time. Every grant and revoke is itself a permanent, visible entry in the ledger.
How trust gets built
"Is this a real person?" and "is this a real, registered business?" are different questions with different answers, so ADULIX tracks them separately rather than folding both into one vague label.
Know Your Customer: confirming the person behind the business is who they say they are. ADULIX verifies this through Fayda, Ethiopia's national digital ID program.
Know Your Business: confirming the business itself is real and properly registered, pulled from the official trade registry rather than a document someone could fake.
Ethiopia's national digital identity program, built as public infrastructure rather than a single company's product. ADULIX's real integration with it is still ahead; today the demo uses a fixed placeholder to show where it plugs in.
Ethiopia's business registry: the official record of what businesses exist, what licenses they hold, and their legal status. ADULIX's connection to it is real, live, and returns actual registry data.
Standards we use
Every piece of how ADULIX proves something is a widely adopted, independently documented standard. That's a deliberate choice: it means anyone verifying an ADULIX credential can use tooling that already exists, not a library only ADULIX ships.
Every ledger entry includes a hash of the entry before it, the same tamper-evidence pattern used by Git commits and Certificate Transparency logs. Change one entry and every hash after it stops matching, so tampering is detectable, not just discouraged.
The open data model the World Wide Web Consortium defines for digital credentials, already used by real-world digital ID and diploma systems. ADULIX's issued credentials follow this shape, not a bespoke one.
A Decentralized Identifier that resolves to a real, public document over plain HTTPS, no blockchain, no special software. ADULIX's issuer identity is did:web:api.adulix.app: anyone can look up its public key the same way they'd load a web page.
The cryptographic signature scheme ADULIX uses to sign credentials, the same one that secures modern SSH, TLS, and secure messaging. It's fast, well-reviewed, and not something this project invented.
A Verifiable Credential encoded and signed as a JSON Web Token, a compact, URL-safe format any standard JWT library can parse. This is the actual signed artifact a QR code in the demo encodes.
Every capability ADULIX has is reachable through its documented HTTP API first; the demo and consent pages are just one client of it, not a privileged one. Anything you see them do, your own code can do too.
Try it
Reading about a trust record only goes so far. These take you straight to the real thing.
Walk the full loop yourself, as both an MSME and a financier, against the real API.
The exact flow an MSME uses to give a partner scoped access and hand them a scannable credential.
Every endpoint, request, and response shape, documented and ready to try directly in the browser.