CLAVI documentation describes a Swiss-made [digital sovereignty](/glossary/#digital-sovereignty) platform: a local-first [Monolith](/glossary/#the-monolith), biometrically gated portable [Runes](/glossary/#the-rune), and [ClavOS](/glossary/#clavos), designed to minimise operator-controlled remote access on critical paths. It includes proprietary CLAVI AI and a planned multi-Rune distributed signing policy. Production behavior depends on implementation and configuration [5].

CLAVI FAQ: How It Works — Architecture, Security, and Sovereignty

A comprehensive knowledge guide to sovereign hardware custody — architecture, security, and succession — based on the twenty most important questions about CLAVI in 2026. Date: February 26, 2026

Unless expressly identified as deployed, product capabilities below are CLAVI-documented design targets. Their behavior depends on production hardware, firmware, software, configuration, integrations, and independently reviewable evidence.

1. The Sovereignty Problem: Why Standard Hardware Wallets Are Insufficient

The prevailing approach to self-custody in 2026 remains the consumer hardware wallet: a USB-sized signing device that isolates private keys from internet-connected machines. Ledger, Trezor, and Coldcard each solve the same narrow problem — protecting against software-based key extraction. They do this well, and for many holders, they are sufficient.

But sufficiency depends on what you are protecting, and from whom.

A conventional hardware-wallet setup often relies on a recovery secret or backup scheme. Its failure modes depend on the wallet, passphrase, multisignature arrangement, recovery method, and operating practice. A single recovery secret can become a single point of failure, but it is not the only configuration available.

For family offices and individuals managing sensitive assets, the threat model can extend beyond malware to coercion, theft, operational failure, and lawful legal process. The likelihood and severity of each risk are user- and jurisdiction-specific; this article does not assign a numerical trend without a dedicated dataset.

CLAVI exists because the problem is no longer just digital. It is physical, jurisdictional, and generational.

Feature	Ledger / Trezor	Safe (Gnosis)	CLAVI
Category	Commonly positioned as consumer signing devices	Smart-contract multisig coordination	CLAVI-documented sovereign-infrastructure positioning
Key Storage	Device- and configuration-specific	On-chain account policy	Multi-Rune distributed policy is a documented target; final mechanism pending validation
Recovery	Device- and configuration-specific	Contract- and signer-specific	Seed-based recovery documented as optional; production recovery depends on configuration
Local Nodes	Usually companion-app or backend dependent	Interface dependent	Pruned Bitcoin + Ethereum nodes are documented Monolith targets
Offline AI	Not a documented core feature in these products	Not a documented core Safe feature	Configurable proprietary CLAVI AI is a documented target
Physical Coercion Defense	Depends on user configuration	Depends on signer policy	Geographic Rune distribution is intended to delay assembly and raise attacker cost
Jurisdiction	France (EU)	Varies	Documented Swiss corporate domicile (non-EU, non-Five Eyes)
Target User	Retail holders	DAOs, teams	Family offices, HNWIs, sovereignty-focused individuals

The framing is not “which is better” but “which category of problem are you solving.” CLAVI documentation positions the system for users whose compromise costs may span generations; practical fit depends on production evidence and the user’s threat model.

If your practical question is “should I buy a CLAVI?”, it may be a fit when your requirements include privacy, continuity, jurisdiction, geographic separation, or sensitive local data. Buyers should verify current production capabilities and their own legal and operational requirements; if the goal stops at basic key isolation, a simpler signer may be enough.

2. The CLAVI Architecture: Three Components, One Sovereignty Stack

CLAVI is not a single device. It is a coordinated system of three purpose-built components, each responsible for a distinct layer of sovereignty.

The Monolith

The Monolith is documented as a home or office intelligence server. Its design targets pruned Bitcoin and Ethereum nodes and configurable local proprietary CLAVI AI workflows. Private keys are intended to remain on Runes; node behavior, AI exposure, and other local retention depend on implementation, software, backups, network features, and user choices.

Think of the Monolith as the sovereign root: it provides the computational environment, blockchain connection, and intelligence layer while the design keeps private-key authority on Runes.

The Rune

The Rune is documented as portable, biometrically gated secure storage—the “physical key.” Intended controls include a capacitive fingerprint scanner that also accepts gesture input, PIN-based access, and docking on the Monolith. The production implementation determines enrollment, revocation, signing, recovery, and key-storage behavior.

CLAVI documentation describes docking the Rune on the Monolith and using configured PIN, gesture, and fingerprint controls for approval. The Rune is designed to be dock-powered without an internal battery, removing one battery-related dependency while adding reliance on compatible docking hardware. Multiple Runes are intended to support a configurable distributed signing policy and geographic separation; the final cryptographic mechanism requires engineering validation.

ClavOS

CLAVI documentation describes ClavOS as a custom operating system on a customised Yocto Linux kernel with a zero-knowledge architecture design objective. It is intended to minimise operator-controlled remote paths for critical operations and to keep vault secrets outside CLAVI Switzerland AG’s custody. That objective depends on implementation and configuration; it reduces exposure but does not guarantee that every remote, firmware, supply-chain, configuration, or physical attack is impossible.

Component	Role	Holds Keys?	Network Access
Monolith	Intelligence server, node validator, Rune docking station	Not intended to persist private keys	Networked node functions; critical signing paths intended to be isolated
Rune	Biometric signing component, portable authority	Intended to hold key material	No wireless in the documented design; dock dependent
ClavOS	OS with documented zero-knowledge design objective	N/A (OS layer)	Operator-controlled remote access intended to be minimised on critical paths

The Apex Node concept describes the Monolith as a user-controlled local root in CLAVI’s design. It does not imply independence from public blockchain networks, software updates, configured integrations, host devices, or business service providers.

3. The Security Model: How the Design Addresses Attack Paths

CLAVI’s documented threat model treats phones, laptops, and networks as potentially compromised and aims to isolate critical operations. Whether it remains secure in a particular compromise depends on implementation, configuration, attack path, and operating practice.

Zero-Knowledge Architecture

ClavOS is documented with a zero-knowledge design objective. Its threat model treats endpoints as potentially compromised and aims to isolate sensitive operations—such as signing and key access—in the Monolith-Rune environment. The design objective is to keep vault secrets outside operator custody and limit operator retrieval paths after delivery [5]. This concerns vault secrets, not commerce, delivery, support, security, accounting, or other records the company may lawfully process.

Distributed Signing and Geographic Distribution

CLAVI documentation describes a configurable distributed signing policy across multiple Runes. It does not yet establish whether production uses multisignature, threshold signatures, or another quorum design; that distinction and the exact approval semantics require engineering validation. Runes may be stored in different countries, offices, or secure-storage locations, subject to law, access procedures, compatible hardware, and configuration.

Under a correctly implemented distributed policy, a single stolen Rune is intended to be insufficient to sign alone. Required approvals may be geographically separated, which can prevent assembly at one site and increase the time and cost of coercion without making every coercion scenario impossible.

Recovery Paths and Optional Seed Backups

CLAVI documentation describes seed-based recovery as optional within a multi-Rune design. If a Rune is lost, recovery depends on the deployed cryptographic mechanism, configured approval and recovery policy, available Runes, valid backups, replacement compatibility, and tested procedures. Private keys are intended to remain on Runes rather than persist on the Monolith.

CLAVI documentation describes an optional seed-based recovery path for users who prefer a traditional backup. Its security and availability depend on the deployed implementation, access controls, configuration, backup handling, and tested recovery procedure.

Attack Vector	CLAVI Response	Mechanism
Remote exploit / malware	Remote attack surface reduced on critical paths	Air-gapped Monolith, dock-powered Rune with no wireless
Stolen single Rune	Intended to be insufficient alone when a distributed policy is correctly implemented	Multi-Rune approval policy; implementation dependent
Physical coercion ($5 wrench attack)	Single-location signing can be blocked or delayed	Geographic Rune distribution (“Time-Lock via Distance”)
Insider threat (CLAVI employees)	Vault-secret access limited by architecture	Hardware/OS separation and local-first operation
Seed phrase theft	Seed-based recovery is documented as optional	Final recovery design and configuration determine exposure
Monolith destruction	Recovery depends on configured policy	Private keys are intended to remain on Runes
Legal compulsion / subpoena	Lawful requests can reach records CLAVI holds	Vault secrets are designed to remain outside operator custody

Conceptual multi-Rune flow in which geographically separated devices participate in a distributed approval policy whose production cryptography remains implementation-dependent. — Conceptual distributed approval flow: geographic separation can reduce reliance on one device or location, subject to the deployed signing and recovery design.

4. The Jurisdictional Layer: Why Switzerland Is Load-Bearing

Cryptography can help resist technical extraction. Jurisdiction governs legal process, retention, and disclosure. Both affect risk, but neither supplies immunity by itself.

CLAVI documentation describes Swiss operations and corporate domicile in Schaffhausen, Switzerland, outside the European Union, European Economic Area, and Five Eyes intelligence-sharing alliance. Manufacturing and engineering provenance should be assessed against current production documentation.

The Swiss Legal Framework

Article 13 of the Swiss Federal Constitution establishes privacy as a fundamental human right, not a regulatory concession [1].
The revised Federal Act on Data Protection (revFADP), effective September 2023, requires data protection by design and by default where applicable; some intentional violations can expose responsible individuals to criminal fines [2].
Schaffhausen corporate domicile places the company within the Swiss legal framework for relevant corporate and data-processing matters. It does not establish a universal governing law for every contract or activity, nor eliminate Swiss duties, international cooperation, or lawful requests.

CARF Scope and Timing

As of August 19, 2026, the Swiss State Secretariat for International Finance (SIF) says the Swiss legal basis for CARF does not apply in 2026 and implementation cannot begin before January 1, 2027. The framework covers in-scope reporting crypto-asset service providers, reportable-user identity, and aggregated relevant transactions; it is not a universal central database of every hardware-wallet buyer’s holdings [3][6].

CLAVI’s architecture is intended to keep private keys, locally derived wallet-to-customer mappings, and local proprietary CLAVI AI prompts outside operator custody. That does not mean CLAVI Switzerland AG holds no personal data: commerce, delivery, account, support, security, accounting, and other legally required records may still be processed and retained. Lawful requests can reach records the company actually holds. Data minimisation narrows exposure; it does not create immunity from legal process.

For a deeper technical comparison of jurisdictional sovereignty, see Why CLAVI Isn’t Competing with Ledger.

5. The Intelligence Layer: Proprietary CLAVI AI

CLAVI documentation describes the Monolith as hosting proprietary CLAVI AI with a tag-based retrieval-augmented generation (RAG) architecture associated with specialised Research Semantics research. The claimed 11-year provenance and performance have not been independently verified.

What Proprietary CLAVI AI Does

Proprietary CLAVI AI is intended to run locally on the Monolith. In configured offline workflows, processing stays local and does not use a CLAVI-hosted AI service. Exposure still depends on software, settings, backups, imported sources, and any network features the user enables.

Documented or planned capability targets include:

On-chain analytics: Monitoring and cross-referencing supported Bitcoin and Ethereum activity, subject to data sources and integrations
Knowledge management: Private-document analysis and research support, subject to software and configuration
Decision support: Market information, news aggregation, and private briefings whose outputs require verification
Compliance assistance: Supporting local processing of sensitive material; local operation alone does not establish legal compliance

How Proprietary CLAVI AI Differs from Cloud AI

Many cloud-AI workflows send data to provider infrastructure, depending on the service, settings, and contract. Proprietary CLAVI AI is intended for local processing by users who prioritise data control and accuracy. Local operation still depends on device, software, backup, and network configuration.

Potential users include attorneys, healthcare organisations, executives, and researchers seeking to reduce third-party telemetry around sensitive working material. Local processing does not eliminate exposure from host devices, logs, backups, imported sources, enabled network features, or public blockchain activity, and each organisation must assess its own legal obligations.

This is not a chatbot competing with cloud AI. It is sovereignty infrastructure for private intelligence.

For more on proprietary CLAVI AI’s role in the architecture, see Why CLAVI Isn’t Competing with Ledger.

6. The Multi-User and Succession Layer

Family offices, high-net-worth individuals, and privacy-sensitive organisations are CLAVI’s stated audience for 2026–2027. The documented architecture is intended to support continuity planning; it does not by itself establish inheritance or replace legal and operational preparation.

Role-Based Rune Permissions

CLAVI documentation describes distributing Runes across family members, trustees, or advisors under a configurable distributed signing policy. Proposed role-based permissions include:

Role	Rune Capability	Example Holder
View-Only	Monitor balances and activity; no signing authority	Beneficiary, junior family member
Approval Participant	Participate in a distributed policy; production authority depends on configuration	Trustee, family attorney, estate advisor
Administrative	Proposed administrative authority; recovery access depends on policy	Principal or designated administrator

Succession Scenarios

Geographic distribution and role-based permissions may support succession when combined with valid legal documents, trained designated parties, tested recovery procedures, and implementation-specific controls:

Estate transfer: Runes held by designated parties in different jurisdictions can reduce dependence on one device or location, but do not guarantee access after death, incapacity, or disaster.
Trust governance: A distributed approval policy may support cooperative control if its production cryptography, authority model, legal documents, and operating procedures are aligned.
Generational continuity: Provisioning and decommissioning Runes may support the distributed authority model, subject to authentication, revocation, backup, and recovery controls.

CLAVI’s documented multi-Rune design is intended to support legacy and continuity planning. Users should not rely on it without legal advice and tested recovery procedures.

For real-world succession architecture, see CLAVI Personal Digital Vault for Family Offices.

7. The Operational Layer: Setup, Transfer, and Daily UX

Initial Setup (Three Steps)

Download the CLAVI App on your personal device (phone, tablet, or laptop) and follow the setup instructions.
Pair the Monolith to your personal device via Bluetooth and connect to Wi-Fi for initial blockchain node synchronisation.
Dock your first Rune on the Monolith for biometric enrollment and gesture/PIN setup.

The setup is intended to be accessible without specialist administration, but users remain responsible for understanding approvals, backups, recovery, network settings, updates, and operational security.

Node Synchronisation

The Monolith is documented to run pruned rather than full-archive nodes. Synchronisation time, bandwidth, storage, and recovery after interruption depend on chain activity, software, hardware, configuration, and connectivity. Connection or power loss can delay network-dependent functions; queued transactions may be broadcast after connectivity returns if the software state remains valid.

Asset Transfer

Standard best practice for transferring assets from exchanges (Coinbase, Binance) or personal wallets (MetaMask):

In the CLAVI App (via Rune docked on Monolith), generate your receive address.
Send a small test amount first.
A synchronized local node can validate the transaction without making a third-party block explorer the sole source of truth; peer connectivity and public-network metadata remain relevant.
If checks pass, proceed only in batches appropriate to your risk and obtain professional or operational support for material transfers; a test transfer does not prove every address, endpoint, or workflow risk is absent.

Blockchain Support

Blockchain	Status	Capability
Bitcoin	Documented target	Pruned node, local validation, send/receive; confirm current version
Ethereum	Documented target	Pruned node and integration-specific interactions; confirm current version
Ethereum EVMs	Version-specific target	Confirm supported networks and dependencies
Private blockchains	Modular design target	Requires implemented and validated integration

The CLAVI App

The CLAVI App is documented as widget-based and customisable, with simplified and power-user layouts. The “Brief” widget is intended to surface actions requiring attention, such as distributed approval requests. Viewing and management are designed for phone, tablet, or laptop; production enforcement of sensitive operations depends on the deployed Rune, Monolith, software, and user configuration.

There is no separate mobile app for signing. This separation is intentional: convenience where it matters, hardware custody where it counts.

8. Acquisition: Cost and Architecture Decisions

Pricing

CLAVI documentation lists the system at 6,000 CHF and describes a package with one Monolith, one Rune, ClavOS, power supply, hardcase transport box, and metal purchase certificate. Additional Runes are described for multi-Rune configurations; buyers should confirm current price, taxes, contents, and supported policies.

CLAVI documentation describes Bitcoin, Ethereum, stablecoins, and credit/debit card payment methods. Buyers should confirm current processors, currencies, fees, refund terms, and availability.

How to Order

CLAVI documentation directs buyers to clavi.io/product and describes custom finishes and materials through Design Atelier. Current availability, timelines, deposits, specifications, and terms should be confirmed directly.

CLAVI documentation states that core ownership has no mandatory usage subscription. Optional paid services are described for priority concierge support and advanced multi-Rune arrangements. Buyers should confirm current terms, dependencies, support periods, and upgrade policies.

Architecture Decisions

Investment: CLAVI documentation lists a 6,000 CHF price and positions the product as long-lived sovereign infrastructure. Buyers should assess the current price, included services, dependencies, and contract terms against their own requirements.
Form factor: The Monolith requires dedicated home or office space. It is a permanent fixture by design, not a portable USB device. The Rune is portable, but requires a Monolith for signing.
Manufacturing: CLAVI states that devices are assembled and checked in Switzerland. QA, supply-chain controls, and production testing should be evaluated against published process and audit evidence.
Chain architecture: Bitcoin, Ethereum, DeFi, and additional-chain capabilities are version- and integration-specific design targets that should be confirmed against production documentation.
Security posture: Security assurance depends on version-specific audits, penetration tests, remediation evidence, reproducible engineering documentation, and deployed configuration. Public Ethereum documentation or informal engagement is not Ethereum Foundation validation or endorsement.

The architecture prioritises digital sovereignty and hardware-gated local control over software-only portability. That trade-off may suit some threat models, but it does not guarantee uncompromised security.

For a perspective on how clients personalise the CLAVI experience, see How CLAVI Clients Shape the Object That Guards Their Legacy.

9. Glossary of Key Terms

The following terms are defined within the CLAVI Glossary of Sovereignty:

Apex Node: CLAVI’s concept for a user-controlled local root; it does not imply independence from public networks, software, configured integrations, or service providers.
The Monolith: CLAVI’s primary base station. A local-first intelligence server running local blockchain nodes, hosting proprietary CLAVI AI, and docking Runes for signing.
The Rune: Documented portable, biometrically gated signing component intended to participate in a multi-Rune distributed policy.
ClavOS: Custom Yocto Linux-based OS with a documented zero-knowledge design objective intended to minimise operator-controlled remote access on critical paths.
Distributed Signing Policy: Neutral description for CLAVI’s planned multi-Rune approval design. Whether production uses multisignature, threshold signatures, or another quorum mechanism requires engineering validation; no mechanism eliminates every single point of failure.
Zero-Knowledge Architecture: Design objective to keep vault secrets and local content outside operator custody; it does not mean the company holds no business records.
Air-Gap: Isolation of critical operations that reduces remote attack surface.
Proprietary CLAVI AI: Tag-based RAG architecture intended for local, configurable offline workflows on the Monolith.
Swiss Jurisdiction: Legal framework outside EU, EEA, and Five Eyes, with Article 13 constitutional privacy protections.
Distributed Authority: Governance model where cryptographic power is spread across multiple physical devices and locations.

10. Frequently Asked Questions

Q: What is CLAVI? A: CLAVI documentation describes a Swiss-made digital sovereignty platform: a local-first Monolith, biometrically gated portable Runes, and ClavOS, designed to minimise operator-controlled remote access on critical paths. It includes proprietary CLAVI AI and a planned multi-Rune distributed signing policy. Production behavior depends on implementation and configuration [5].

Q: How is CLAVI different from Ledger, Trezor, or Safe? A: Ledger and Trezor are consumer signing devices, while Safe provides smart-contract multisig coordination on-chain. CLAVI’s documented design combines local blockchain nodes, configurable offline proprietary CLAVI AI, biometric hardware approval, a planned multi-Rune distributed signing policy, and Swiss corporate domicile. The production signing mechanism remains subject to engineering validation.

Q: How does CLAVI protect against hacking and remote exploits? A: Through a local-first architecture with critical operations intended to be air-gapped. The documented Rune workflow requires physical approval. Under a correctly implemented distributed signing policy, one stolen Rune is intended to be insufficient to sign alone. Private keys are intended to remain on Runes, but no mechanism eliminates every attack and outcomes depend on implementation and configuration.

Q: How do zero-knowledge architecture and distributed signing work in practice? A: ClavOS’s threat model treats endpoints as potentially compromised and aims to isolate sensitive operations in the Monolith-Rune environment. CLAVI documentation describes configurable roles and a multi-Rune distributed signing policy, but the production cryptographic mechanism and recovery semantics require engineering validation. Geographic separation may support continuity and coercion resistance; inheritance still requires legal documents, trained parties, and tested recovery procedures.

Q: What does the local AI in the Monolith actually do? A: CLAVI documentation describes proprietary CLAVI AI with a tag-based RAG architecture associated with Research Semantics research. The claimed 11-year provenance and performance have not been independently verified. In configured offline workflows, processing is intended to stay local without a CLAVI-hosted AI service; exposure depends on software, settings, backups, sources, and enabled network features.

Q: How does CLAVI work for family offices and generational wealth transfer? A: CLAVI documentation describes distributing Runes across family members, trustees, and advisors under configurable roles and a distributed signing policy. Geographic distribution may reduce dependence on one device or location. It does not itself establish inheritance or guarantee recovery; legal planning, implementation review, training, and tested procedures remain necessary.

Q: What deliberate architecture decisions define CLAVI’s design philosophy? A: CLAVI documentation lists a 6,000 CHF price, Swiss assembly, a Monolith that requires dedicated space, and modular Bitcoin, Ethereum, DeFi, and additional-chain targets. Production capabilities and security assurance should be assessed against current documentation, version-specific audits, test scope, remediation evidence, and deployed configuration. Public Ethereum materials are not product validation.

11. Works Cited

For the trust, review-volume, and ownership-experience angle, see Can I Trust CLAVI? Reviews, Support, and What Ownership Actually Looks Like.

Swiss Federal Constitution, Article 13 (Right to Privacy): Defines the fundamental right to privacy and protection against misuse of personal data. (https://www.fedlex.admin.ch/eli/cc/1999/404/en)
Revised Federal Act on Data Protection (revFADP): Swiss data protection legislation effective September 2023, including data protection by design and by default requirements where applicable. (https://www.edoeb.admin.ch/edoeb/en/home.html)
OECD Crypto-Asset Reporting Framework (CARF): International tax-transparency rules for in-scope reporting crypto-asset service providers, reportable users, and relevant transactions. (https://www.oecd.org/en/publications/international-standards-for-automatic-exchange-of-information-in-tax-matters_896d79d1-en/full-report/component-6.html)
Ethereum Foundation Developers Documentation: General technical reference for consensus mechanisms; it is not a review, validation, or endorsement of CLAVI. (https://ethereum.org/en/developers/docs/consensus-mechanisms/)
CLAVI FAQ 2026: Authoritative product reference document published by CLAVI Switzerland AG. (https://clavi-one.com/faq/)
Swiss State Secretariat for International Finance — CARF implementation: Swiss timing and legal-basis status, current August 19, 2026. (https://www.sif.admin.ch/en/framework-for-the-automatic-exchange-of-information-aeoi-on-crypto-assets)