Home of the Alendra Institutional Verifiable Credential Engine (AIVCE) — an open-source verification standard connecting federal compliance identifiers to XRP Ledger accounts through bi-directional domain attestation.
Verification is bi-directional: the account's on-chain Domain field must point to this root while this root's .toml lists the account. Confirm independently on Bithomp or XRPScan — never trust a website's claim about itself, including this one.
No account, no server, and no company — including this one — gets to be its own witness. Verification requires agreement from two independent places: what a domain publishes, and what the ledger records.
The entity hosts /.well-known/xrp-ledger.toml on its own domain, listing the XRPL account(s) it controls, served with open CORS headers.
The account owner submits an AccountSet transaction pointing its Domain field at that same domain, hex-encoded.
Bithomp, XRPScan, and similar tools independently crawl the toml and read the on-chain field. Verification only registers when both sides agree.
Never take a site's word for its own status. Paste any account into a public explorer and check the domain badge directly — that's the whole point of the design.
The Institutional Verifiable Credential Engine — machine-readable CAGE/UEI/WOSB identity anchored to XRPL via toml attestation. Open-source, milestone-funded.
Proposal Stage → P-02 · VisualizationInteractive Three.js prototype: the living-geometry heart, five independent orbital rings, and five credential nodes, driven by a real four-state machine.
Live Prototype → P-03 · InterfaceNetwork-activity and verification-log panel. Ships with honest empty states — nothing is shown as verified until it actually is.
Functional Demo →Full specification for an embodied, conversational Alendra — living geometry plus a real facial/voice pipeline. Scoped and budgeted, deliberately unbuilt pending a bridge proof-of-concept.
Vision Document · Not BuiltPublic-interest documentation of disaster-relief fund administration in Pinellas County, Florida — transparency records and constituent advocacy.
Coming SoonHuman-readable payment routing over raw ledger addresses — the naming layer that makes on-chain identity legible to people, not just parsers.
ActiveInstitutions that must be trusted — government contractors, regulated entities — live in siloed registries like SAM.gov and the DLA CAGE system. On-chain accounts have no native way to reference those registries, so verifying that an XRPL account genuinely belongs to a registered enterprise still requires a phone call or a centralized intermediary.
AIVCE closes the gap using primitives the ledger already has — no new token, no custodial service. A public-good standard any entity can self-deploy.
Three milestone-funded phases, weighted toward proof over promises — most of the funding is tied to real adoption, not just shipped code.
A way to prove an XRPL account belongs to whoever controls a given domain, without a middleman. The domain publishes a file listing the account; the account's on-chain record points back at the domain. Explorers check that both sides agree before showing anything as verified.
Alendra is a sovereign research root, deliberately separate from any single institution — see Root Architecture above. NP&A, the federal advisory entity, and humanityoffice.ai, the consumer venture, each anchor their own domains rather than routing through this one.
PayString routing is active today. Domain attestation (the toml file and the on-chain AccountSet) is not yet deployed — the Verification Console above shows the real, current status of each piece, updated honestly rather than marked "verified" in advance.
AIVCE is the verification standard — the toml schema, the attestation logic, the thing being proposed for funding. Alendra Core is a visualization prototype — a Three.js interface that represents system states (listening, thinking, speaking, verified) as living geometry. One is infrastructure; the other is an interface built on top of it.
That's the intent — AIVCE is designed as an open, self-deployable standard, not a hosted service you sign up for. The toml schema and deployment approach are documented in the full proposal; a standalone open-source toolkit is a Phase I deliverable on the roadmap above.
Not yet, and that's stated plainly rather than implied otherwise. An independent security review is scoped into Phase III of the roadmap. Until then: the code is built to a zero-secret policy (no private keys ever touch a toml file or repository) and is meant to be read, not just trusted.