Sovereign digital identity infrastructure

The infrastructure for issuing, verifying, and governing verifiable credentials — open source, sovereign by design, and built so any institution can participate in the trust root. No single point of failure, no single point of control.

01 Station Verify, sign, and safeguard your documents — all on your own computer. Nothing leaves your device unless you decide.
02 Web Extension Log in to any website with no username and no password, and sign documents with one click — your data stays private, your accounts stay yours.
03 Mesh Stations, extensions, and mobile apps can join a shared, encrypted network — your data lives across the community, not on a single server.
A founding principle

Open tools. Institutional infrastructure.

Verification, signing, and identity tools are open source — anyone can use them, audit the code, and build on top. Professional and institutional services — credential issuance, organizational trust, regulatory compliance — fund the infrastructure through transparent per-transaction fees. The tools stay open because commerce sustains the network.

Who this is for

Ark is open infrastructure offered to the institutions, professionals, and developers who have to make sovereign digital identity real. Find the role that fits you.

Government

Regulator or public institution

National regulators and public institutions. Evaluate the architecture, request a briefing, and explore institutional participation.

Request institutional briefing →
Notary · Lawyer · Accountant

Daily Firma Digital user

If you live with the "signature validity unknown" red banner every day, Station is built for you. Verify CR-signed PDFs natively.

Get early access to Station →
Institution

Bank, insurer, university, KYC operator

Run a pilot on a real onboarding or signing flow. Issue verifiable credentials your counterparties can verify offline.

Propose a pilot →
Developer

Open source contributor

Every component is open source. Read the code, file issues, ship a module, fork a country deployment.

Browse the repos on GitHub →
LATAM partner

Operator outside Costa Rica

Stand up a sovereign CA in your jurisdiction with your own shareholders and your own ceremony. The architecture is one-per-country by design.

Deploy in your country →

Five pillars, one architecture

Start with one component and grow into the full architecture. Onboard progressively — deploy Station today, add the Web Extension tomorrow, join the Mesh when ready. Every step adds value, and the full architecture is greater than the sum of its parts.

□

Station

Electron desktop application. Your verification station, credential vault, and mesh network node.

  • Document verification with OCR and census
  • Encrypted local vault with xsalsa20-poly1305 + scrypt
  • Electronic signature today; smartcard Digital Signature (PKCS#11) planned
  • Opt-in mesh node — join the P2P network when ready
◇

Web Extension

Browser extension that validates document signatures and CA trust in the page, surfaces a trust score, and connects to the Station for verification flows.

  • Client-side certificate validation
  • Trust score surfaced in the browser
  • Wallet adapter discovery for signing
  • Bridges browser pages to the Station
⊙

Mesh

Encrypted P2P network over libp2p. State synchronization between local devices and national nodes without a central server.

  • Blind Courier principle — nodes can't read the data they carry
  • Compact per-citizen footprint
  • Works offline, syncs when connected
  • Cryptographic anchoring on a public ledger
⚙

Ceremony

Sovereign appliance for CA key ceremonies. Air-gapped Linux laptop, Shamir share distribution via local mesh.

  • Clean Linux laptop (live USB)
  • Key is split, original is destroyed
  • vLEI verification of shareholders (planned)
  • PKCS#11 support per jurisdiction (planned)
☍

Trust

CA trust framework with Shamir shareholders, public on-chain transparency, and governance distributed across institutions.

  • CA key split: 2-of-3 today, extensible to 3-of-5 with institutional partners
  • Trust root at vault.attestto.sol
  • Auditable blockchain transparency
  • No actor has unilateral control

Desktop to mobile verification

Desktop and phone work together over local WiFi. Images and biometric data never leave your network — the connection is direct, no servers or cloud.

1

Open Station on your desktop

Select the document type to verify. Station generates a unique session QR code.

2

Scan the QR with your phone

The QR opens the mobile app with the WebSocket connection preconfigured. Your phone connects directly to your desktop.

3

Capture document and selfie

Front, back of document, and selfie with liveness proof (blink detection). Everything transmits in real-time to the desktop.

4

Automatic processing

Station runs OCR, extracts MRZ data, validates the document, and generates the verifiable credential.

5

Credential in your vault

The credential is stored encrypted in the local vault. Sign it with Digital Signature, anchor it on a public ledger, or share it via verifiable presentation.

Local network architecture

The connection between desktop and mobile is direct over local WiFi. No intermediary servers, no cloud, no internet dependency.

Privacy is not a policy — it is a mathematical guarantee.

□ Station WebSocket + OCR + Census + Vault
↕ Local WiFi No internet, direct connection
◇ Web Extension Camera + Liveness + VCs

Distributed trust by design

The Certificate Authority private key is split using Shamir's Secret Sharing. No individual actor — including Attestto — can sign unilaterally.

⋆

Shamir's Secret Sharing

The CA Ed25519 key is generated in an air-gapped ceremony and split into N shares. A threshold K is required to reconstruct it. The original key is destroyed.

Phase 1A (current): 2-of-3 founder-only
Phase 1B: reshare to 3-of-5 as institutional partners join
Phase 2+: threshold grows with the shareholder set
⚖

Institutional shareholders

Phase 1A is founder-only with all shares held by Attestto. Institutional shareholder positions are reserved for Phase 1B once formal partners join. Each share alone is useless — only when the threshold gathers can the key be temporarily reconstructed.

Attestto — Technical operator (Phase 1A — current)
Reserved — Institutional partner positions (Phase 1B)
Reserved — Independent auditor position (Phase 1B)
♦

Public attestation log

Ark is chain-agnostic by design. The W3C VC, W3C DID, GLEIF vLEI, and eIDAS standards do not depend on any single ledger. CA events will be anchored as public on-chain attestations — providing sovereign naming, sub-second public commitment, and a per-event cost compatible with institutional rollout. Each jurisdiction can choose its anchoring layer as institutional partners require; credentials issued under one anchor remain verifiable under another.

Root: vault.attestto.sol
Record: Each CA event → on-chain attestation (planned)
Verification: Public and open
GLEIF + ISO 17442

vLEI Verification

Every shareholder must hold a verified LEI (Legal Entity Identifier) and a vLEI issued by GLEIF before joining a ceremony — proving they legitimately represent their institution. On-chain verification path is planned.

Pre-requisiteActive LEI + issued vLEI
VerificationOn-chain attestation (planned)
StandardGLEIF + ISO 17442

Sovereign, air-gapped, verifiable

The CA key generation ceremony occurs in a completely isolated environment. No internet connection. The only network is an encrypted local mesh between shareholder devices.

⚓

The sovereign appliance

A clean Linux laptop boots from live USB. No hard drive, no history, no external network. The ceremony software creates a private WiFi mesh to distribute Shamir shares to shareholder devices.

  • Linux live USB — no hard drive
  • Local WiFi mesh — no internet
  • Generate Ed25519 key pair
  • Split into Shamir shares
  • Destroy original key
  • Auditable, filmed ceremony
↺

Ceremony types

The system supports different ceremonies according to the CA lifecycle.

Genesis: First CA key generation
Rotation: Re-split with new shareholders
Signing: Reconstruct to sign certificates
Revocation: Revoke compromised key
☽

Multi-jurisdiction

Each country has its own electronic signature scheme. The appliance supports PKCS#11 to integrate with local signing hardware.

Costa Rica: National digital signature framework (planned)
Brazil: National PKI infrastructure (planned)
Mexico: Federal electronic signature (planned)

Four paths to the sovereign web

The ultimate goal: TLS certificates issued by Attestto CA recognized natively by browsers. Four parallel paths, each with a different time horizon.

Now

Browser extension

The Attestto ID extension validates certificates client-side against vault.attestto.sol and surfaces a sovereignty trust score in the browser. Day-1 deployment, no DNS infrastructure changes.

6 months

DANE / TLSA

Publish TLSA records in DNS pointing to Attestto CA certificates. Requires the domain to use DNSSEC. DANE validators already exist in some browsers.

12 months

Verification proxy

A bridging service that lets sites cross-publish their Attestto-issued certificate alongside a globally-trusted certificate, so browsers without DANE or the extension still see a valid chain while the sovereign certificate is recognized by participating clients.

2-5 years

W3C / IETF Standards

Participate in standards working groups so browsers natively recognize CA roots anchored in decentralized registries (blockchain, IPNS, decentralized naming).

One CA per jurisdiction

Each jurisdiction operates an independent Certificate Authority, key ceremony, and governance scheme. Each is anchored as a sovereign root on a public ledger.

Beta
🇨🇷

Costa Rica

fi-cr.sol · go-cr.sol · sa-cr.sol · ed-cr.sol · or-cr.sol

A namespace per sector — finance, government, health, education, organizations — and one for each province and municipality. Designed to integrate with national census, payment infrastructure, and digital signature frameworks.

Proposed
🇧🇷

Brazil

fi-br.sol · go-br.sol · sa-br.sol · ed-br.sol

A namespace per sector. CPF, CNH, digital RG. Integration with ICP-Brasil and gov.br.

Proposed
🇲🇽

Mexico

fi-mx.sol · go-mx.sol · sa-mx.sol · ed-mx.sol

A namespace per sector. INE, CURP, federal license. Integration with e.firma SAT.

🌎

Your country

fi-xx.sol · go-xx.sol · sa-xx.sol · ed-xx.sol

Each jurisdiction deploys its own sovereign CA — one namespace per sector, one per province — with its own governance and institutional shareholders.

Get involved

If any of the roles above fits you, write to us. We are looking for the institutions, professionals, and developers who want to help build sovereign digital identity in the open.

Contact the team