❄

How is a keyactually born?

A FrostCard has no seed phrase. No twelve words to write down. Instead, it makes its own secret — inside a sealed chip, in about 27 milliseconds, faster than you can blink. Here is exactly what happens in that instant, and why the secret can never leave.

Watch the moment ↓

Lesson 1

A secret that no human ever sees

🔒

A vault that forges its own lock

When you tap a brand-new FrostCard, it does not receive a key from the app, from a server, or from a factory. The chip inside the card builds its own key, entirely by itself. The app is only ever handed the public half — the part you're allowed to share. The secret half is born sealed and stays sealed.

That chip is called a secure element — the same class of tamper-resistant silicon used in passports, SIM cards, and bank cards. It's built so that the secret it holds can be used but never read out. Not by the app. Not by your phone. Not by us.

In plain wordsThe card doesn't get a key. It creates one — and the only copy lives behind a wall that has no door.

Lesson 2

Where does the randomness come from?

A key is only as safe as the randomness behind it. If an attacker can guess how your randomness was made, they can rebuild your key. Ordinary software randomness can be predicted — it comes from a formula. FrostCard does not use it.

🎲

Dice carved out of physics

The chip has a hardware True Random Number Generator (TRNG) — a tiny circuit that measures real physical electrical noise inside the silicon and turns it into numbers. Physics, not a formula. There is no seed to predict and no pattern to replay. These generators are tested against strict standards (AIS-31, NIST SP 800-90) precisely to prove the output is unpredictable.

What a TRNG isA normal "random" number in software is really a formula that looks random — feed it the same start and it repeats. A TRNG measures something genuinely unpredictable in the physical world, so there's nothing to feed it and nothing to repeat.

The first thing that happens in the key's life: the TRNG produces 32 bytes of pure physical chance. Tap below to mint 32 random bytes in your browser — then read the note underneath, because it matters.

32 bytes from the generator

Lesson 3

Those 32 bytes are the key

There is no extra step. That random number, all by itself, is your private key — a single enormous whole number. (Technically it's a number below a fixed limit set by secp256k1, the elliptic curve Kaspa uses. The chip checks it falls in range; if not, it simply rolls again.)

How enormous? 32 bytes is 256 bits — that's this many possible keys:

2²⁵⁶

≈ 115,792,089,237,316,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

More possible keys than there are atoms in the observable universe.
Guessing yours is not "hard." It is, for any machine that could ever exist, impossible.

Private key, in plain wordsIt isn't a password you choose. It's one specific, gigantic random number. Whoever knows that number controls the funds — which is exactly why it's made in the dark and never shown to anyone.

The Window

What happens in that instant

People imagine this takes "about a second." It doesn't. On this class of chip the entire cryptographic birth measures around 27 milliseconds — faster than a blink — and nearly all of that time is spent on a single piece of math: deriving the public key. Everything else is near-instant.

Here is the exact sequence the card runs, straight from FrostCard's open-source applet code:

1

Roll the dice ~1 ms

The hardware TRNG produces 32 bytes of physical randomness into temporary scratch memory (RAM that's wiped the moment the card leaves the reader).

2

Seal it in ~3–5 ms

The key is written into the chip's permanent memory (EEPROM) as a protected key object. Permanent writes are slow compared to RAM — that's why this costs a few milliseconds instead of none.

3

Make the public twin ~20–32 ms ◆ the slow step

The chip's crypto coprocessor multiplies the secret by a fixed point on the curve (k·G) to derive the public key, then compresses it to 33 bytes. This one operation is the bulk of the whole window.

4

All-or-nothing commit ~few ms

The private key, the public key, and a "wallet exists" flag are committed together as one atomic transaction — so a power cut mid-birth can never leave a half-made key.

5

Wipe the workbench <1 ms

The temporary scratch copy of the secret is overwritten with zeros. From here, the only copy lives inside the sealed key object.

6

Lock the door — forever instant

A one-time flag flips. This card can never generate a key again. Only its 33-byte public key is handed back to the app.

Honest note on timingThese are measured figures for this class of secure element: full on-card key generation runs about 27 ms (25–31 ms) on the NXP J3R180 / J3R200 (JCOP4, SmartMX3 P71), per independent JavaCard benchmarks (JCAlgTest, CRoCS / Masaryk University) and a peer-reviewed 2023 study measuring the exact J3R200. The elliptic-curve math (~20–32 ms) dominates; everything else is near-instant. The point isn't the exact millisecond — it's that the slow part is one well-understood calculation, and the secret never travels anywhere during it.

Going Deeper

Three questions you should be asking

Why can't a half-made key ever exist?

Imagine the power dies between writing the secret and recording that the wallet exists. You'd have a card holding a "ghost key" the app knows nothing about. FrostCard prevents this with an atomic transaction: a guarantee that a group of changes either all take effect or none do. Step 4 wraps the whole commit, so an interrupted birth simply rolls back to "blank card" — never a dangerous in-between.

If the public key is derived from the secret, can someone reverse it?

No — and this is the heart of it. Multiplying a secret by a point on the curve (k·G) is a one-way street. Going forward is fast. Going backward — recovering the secret from the public key — means solving the elliptic-curve discrete logarithm problem, which no known computer can do in any practical time. So the card can safely hand out the public twin while the secret stays unguessable.

If there's no seed phrase, what do I back up?

Nothing on paper. Because the key is born sealed and never leaves silicon, there are no words to write down (and nothing for a phishing site to ask for). Instead, during setup the key is copied chip-to-chip to your backup cards over an encrypted channel, then the set is permanently locked. The cards are the backup.

Don't Trust — Verify

Read the code that makes the key

Every line of code that touches your key is public. The birth sequence above is the generateKey() method of FrostCard's JavaCard applet — you can read it, line by line, yourself.

The applet — KeyManager.java

The exact generateKey() routine: TRNG → seal → derive public twin → atomic commit → wipe → one-time lock.

The security contract

Keys stay in silicon. Nothing outside the card may accept, store, transport, or cache the private key — not raw, not encrypted, not split. It's the first non-negotiable rule of the project, and the reason the key is born the way you just saw.