Hey ICP community,
Building something I wanted to share before mainnet
— mostly interested in technical feedback from people
who’ve shipped on ICP.
WHAT I BUILT
A sovereign data vault platform where each user gets
their own isolated canister, spawned at registration.
Data never commingles across users. 500GB per vault.
The main use case is biological data but the
architecture is the interesting part.
ARCHITECTURE
4 canisters:
aeterna_backend
Main logic, canister factory, daily heartbeat sealing,
genesis/whitelist management, inter-canister reward
calls to the token canister.
aeth_token
ICRC-1 token with a per-user reentrancy guard
(HashMap<Principal, Bool> — replaces a global Bool
to allow concurrent users without blocking each other).
Reward functions only callable from the backend
canister principal (set via set_backend_canister()).
doc_registry
Global cross-vault document hash registry.
Prevents duplicate document processing across
all user vaults. Persistent actor with stable storage.
aeterna_frontend
Standard asset canister.
ICP FEATURES USED
vetKeys
Every user’s daily data record is sealed using
vetKeys threshold cryptography via the heartbeat.
Sealed blocks are immutable — neither the founder
nor anyone else can alter them post-seal.
This is the core trust mechanism for the platform.
Has anyone else shipped vetKeys in production?
Would love to know if there are gotchas I haven’t hit yet.
Per-User Canister Factory
At registration (forge), aeterna_backend spawns
a SovereignVault sub-canister for the user and
transfers 2T cycles to it. The vault canister ID
is returned to the frontend and stored.
Question: is 2T cycles a reasonable allocation
for a 500GB capacity vault at current cycle pricing?
Internet Identity
No passwords, no email. The vault is cryptographically
bound to the user’s II principal. Per-user data
isolation enforced at the canister level, not just
application logic.
ICRC-1 Token
AETH token with earn model — the token canister
receives reward calls from the backend canister only
(not directly from the frontend). Designed this way
to prevent client-side reward manipulation.
No pre-sale, no VC allocation.
Heartbeat
Used for daily Chronicle sealing at midnight UTC
and notification triggers. Also tracks cycle balance
snapshots for operational monitoring.
Chain Fusion
Wallet supports ICP, AETH, and ckUSDC natively.
Planning ckBTC/ckETH in a later phase.
SECURITY DECISIONS
- Anonymous principal blocked on all public functions
- Per-user processing guard on token operations
- Rate limiting on data ingest endpoints
- Document authenticity verification pipeline
before any AI processing - ML-KEM-768 post-quantum keypair generated
at vault forge (via @noble/post-quantum) - AES-GCM-256 on all localStorage via vault keys
- Production build strips all console output
CURRENT STATUS
All 4 canisters compile clean.
Frontend builds clean (TypeScript zero errors).
Local smoke tests pass.
WSL clock drift was the mainnet blocker —
confirmed resolved, deploy imminent.
GitHub will be made public at mainnet launch.
GENESIS 100
First 100 users. Founding vaults only.
my X: https://x.com/AeternaVault
QUESTIONS FOR THE COMMUNITY
-
vetKeys in production — any known issues
with the current testnet key vs mainnet key_1?
Any timing considerations for the heartbeat seal? -
Per-user canister spawning — at 100 users
this is fine, but what’s the recommended
pattern for monitoring child canister cycle
balances at scale? -
Upgrade safety — using persistent actor model
throughout. Any migration patterns for stable
variable type changes that people have found
work well in production?
Happy to answer any technical questions.
— Borislav