Arcanum

There is no truly trustless, cost-efficient, and censorship-resistant way to manage secrets.

Arcanum is a Secrets manager that eliminates trust in centralized providers like AWS, Azure or HashiCorp Vault. Secrets are stored on Ethereum, encrypted with FHE.

You can stop paying 0.4$ per secret, per month financing Bezos' next yacht. The personal cloud is finally here.

Either you are a single person, or any organisation you can securely store your secrets and store key-value secrets with a granular Access Control List which operates on two-levels:

Namespace level Secret level

Secrets can expire and access can be revoked.

Arcanum can work if you are a person, a server or an agent. It ships with a dApp, a CLI tool, an SDK and an Agent skill allowing non-technical people, or agentic swarms to securely access, store and share secrets.

The Vault smart Contract is built with Solidity on Foundry, and OpenZeppelin libraries.

We use Fhenix for FHE operations. Each Namespace and each Secret gets its own FHE-encrypted AES key generated on-chain.

The SDK uses a hybrid encryption scheme:

FHE keys are decrypted client-side via FHE permits, then used as AES-256-GCM keys to encrypt/decrypt secret values. This avoids the overhead of FHE on large payloads while keeping key management fully on-chain.

The dApp is built with React + Vite + Tailwind. Dynamic for wallet and social login, wagmi for chain interaction, and React Query for state.

ENS resolution supports both forward and reverse lookups.

The CLI wraps the SDK for terminal workflows, and a Claude Code skill enables AI agents to manage secrets via natural language, a key use case for autonomous agent infrastructure.

We deployed on Base Sepolia for speed and for the fact that Fhenix was the most stable there.

The "hacky" part of our solution was using good standards to not lose the trustlessness while overcoming current limitations. Since we can only store 32 bytes per secret on-chain we encrypt a key onchain and we use this to locally wrap the Secrets on the client side.

Additionally, to avoid complex logic onchain we wrap the Secret twice to allow for namespace level access and secret level access (in case you want to share only one secret and not everything).

We did hit a few hijinks as FHE is still young, especially on localhost, and we had to shiv our way through the problem via a postinstall script. We also had to Mock some FHE methods for our tests. These will be all be old problems soon.