The correct approach is to write down seed phrase backups as a documentation task with a fixed procedure. Verify what you are copying, record it legibly, read it back against the screen, then store it where one accident cannot destroy it. This guide covers the mechanics, the failure modes that surface years later, and the checks that catch a mistake before the wallet holds anything worth taking.

• The phrase is the wallet. Every key in a standard wallet is derived from those words, so a copy is a spending credential, not a password that can be reset.
• Transcription errors are recoverable, exposure is not. A checksum usually rejects a bad copy at import; a photographed copy fails silently years later.
• Medium matters more than concealment. Paper, archival paper and stamped metal differ in what they survive, not in how well they hide.
• An unverified backup is a guess. Only a real restore test on a spare device proves the copy works.

Why the recording step decides the outcome

The seed phrase is the wallet. Standard wallets derive every private key from that one string, so anyone holding it can rebuild the same addresses on a compatible device and spend from them. There is no password reset and no support channel that can restore access.

That shapes the whole exercise. You are not backing up a password that can be changed after a leak. You are producing a durable copy of a secret whose value is the entire balance it controls, including accounts you have not created yet.

What the phrase actually encodes

A typical phrase is 12 or 24 words drawn from a fixed list of roughly two thousand, with the last word carrying a checksum. The checksum lets a wallet reject many transcription errors immediately: transpose two words or misspell one and the import usually fails instead of quietly opening an empty wallet.

That protection is narrower than it feels. It catches errors that change the word sequence, not a copy stored where someone else can read it.

What a bad copy costs

A bad copy fails in one of two directions. If it is illegible or incomplete, you discover it when you try to restore, usually the moment you most need access. If it is legible and exposed, you may never discover anything until the balance moves without you.

The second failure is the expensive one because it is silent. A photograph in a cloud library, a note in a synced app, a page in a drawer someone else can open: each is a full copy of the keys with weaker protection than the device it came from.

How to write down seed phrase material without introducing errors

Write on a surface that will not move, with a pen that will not fade, and read each word aloud before copying it. Speed is the main source of mistakes when you write down seed phrase material, so lay out the materials before the wallet generates anything.

Legibility and permanence

Pencil smudges, and thermal receipts fade to blank within a few years. A marker on ordinary paper stays legible but is vulnerable to water. Archival paper and pigment ink are better; stamped metal is better still against fire and flood, at a higher cost and with reading problems if the stamping is shallow.

Order, numbering and cross-checks

Number every word. Adjacent words in the list often look alike at a glance, and numbering makes an omission obvious when you read the copy back. Note the word count at the top, and avoid any label that tells a stranger what the paper is.

Storing a seed phrase backup: paper, metal and split copies

Storage media differ mainly in what they survive. Choose based on the threats you actually face, which are usually fire, water, a move or a visitor with five unsupervised minutes.

Split storage needs a scheme, not two envelopes. If half the words sit in each place, losing either destroys the backup. A design where any two of three locations are enough requires more discipline than most people sustain, so document the scheme separately and test it.

Verify the backup before you fund the wallet

Verification is a restore test, not a visual check. Reading the paper against the screen confirms transcription; only an import confirms that the copy works. Do it while the wallet is empty.

1. Prepare a spare device. Use a second app or a hardware device on the same standard, with no funds on it.
2. Read from the paper. Import using only the written copy, so the test exercises the artifact rather than your memory.
3. Compare the first address. The restored wallet should generate the same receiving address. If not, stop.
4. Check the word count. Confirm the restore accepted every word and did not silently drop the last one.
5. Wipe the test device. Reset it so the check leaves no second live copy on hardware you may resell.
6. Record the date. Note when the check happened, somewhere separate from the backup.
7. Repeat after any change. Adding a passphrase or migrating wallets means a new backup and a new test.

Run the test when you create the wallet and again after any move or re-engraving. A backup that has never been restored is a belief, and beliefs are what people discover were wrong at the worst moment.

A seed phrase backup is not a record of what you own today; it is the instruction set for recovering everything you will own under that wallet.

The post Seed Phrase: Writing It Down Correctly appeared first on FogChain.

Getting mobile wallet security right means deciding what the phone may hold, what needs a second device, and what should never be signed on a small screen at all. This guide covers the threat model, the key storage options, and a routine you can run in ten minutes a month.

• The unlocked phone is the attack surface. Most mobile losses involve a device that was open, borrowed, or running something it should not.
• Key storage is the real differentiator. Keys kept in the operating system’s protected store behave differently from an encrypted file in app storage.
• Small screens hide details. Address truncation and preview panels make mobile a poor place to approve large or unusual transactions.
• Separation beats configuration. A phone wallet for daily spending plus an offline setup for savings removes the decisions that fail under pressure.

What mobile wallet security actually protects

It protects the keys and the signing step. Everything else, including the app interface, the node it queries and the token list it displays, is a convenience layer that can be wrong without costing you anything, as long as the keys stay out of reach.

What the app can and cannot do

A non-custodial app holds an encrypted copy of the key material and asks the operating system to decrypt it when you approve a transaction. The app can start a signature; it cannot complete one without your approval, unless it has been modified to try.

That clause is the whole game. A tampered app, a malicious keyboard or a screen overlay that captures what you type all break the assumption. Install from official sources, keep updates on, and treat any request to sideload a wallet build as a red flag.

The phone is the threat model

A phone is lost, stolen, borrowed, repaired and resold. Each of those is ordinary, and each is a chance for someone else to hold a device that can sign.

Device compromise

Compromise usually looks mundane: an old device with no passcode, a repair shop with the phone unlocked, or a backup that restores onto new hardware without asking. Encryption and a long passcode cover most of it, and neither helps if the device is handed over open.

Check the basics. Auto-lock at the shortest interval you tolerate, a passcode rather than a pattern, no notification previews for wallet apps, and a habit of locking before the phone leaves your hand.

Permissions, overlays and the clipboard

Every permission is a channel. Accessibility access can read the screen, draw over it and simulate taps, which is enough to turn a legitimate approval into something else. Screen recording and notification access matter for the same reason.

The clipboard is a quieter channel. Copying an address and pasting it into a wallet means whatever wrote to the clipboard last decides where funds go, and some malware watches for address-shaped strings and swaps them. Read the pasted address character by character, or scan a code instead.

The lock screen is not a security feature you enable once; it is the only thing between a lost phone and a signed transaction.

Where the keys live on a phone

Key storage separates wallets that look identical. The interface tells you nothing about whether the key sits in a protected hardware store or in a file the app reads with a password.

Software storage with an encryption password

Older or simpler wallets keep an encrypted key file in app storage and decrypt it with your password. That works, but the decrypted key exists in memory while the app runs, and a compromised device can capture it.

Hardware-backed keystores

Many phones expose a protected store where keys can be generated and used without leaving the chip. A wallet built on it can require a biometric check per signature, which raises the cost of a stolen unlocked device. Support varies by model and by wallet, so confirm the wallet uses it rather than merely mentioning it.

Pairing a hardware signer

A hardware signer keeps the key off the phone and asks you to confirm on its own screen, over a cable, Bluetooth or a QR code. That screen is the point: it shows destination and amount without the phone being able to alter them.

Comparing mobile wallet security setups

No setup wins on every axis. The useful question is which failure each one tolerates, and whether you could survive it.

Most people end up with two of these: a hot wallet holding a small balance, plus a hardware signer or a watch-only view for the rest. The split matters more than the brand of either.

A hardening routine for a phone that holds keys

Run this once at setup, then repeat the checks quarterly. None of it is exotic and all of it is cheaper than one bad approval.

1. Set a long passcode and a short auto-lock. Six digits is a floor, not a target; alphanumeric is better if you can tolerate it.
2. Remove wallet apps from notification previews. A lock-screen message naming a balance tells a stranger what the phone is worth.
3. Audit accessibility and overlay permissions. Revoke anything you cannot explain, especially apps that draw over others.
4. Keep the operating system current. Delayed updates leave known flaws open, and wallet users are worth targeting.
5. Require biometric confirmation per signature. A wallet that signs without a check turns an unlocked phone into an open safe.
6. Separate balances. Keep a small amount on the phone and move anything larger to a key that is not on it.
7. Record which device holds what. A written mapping turns a lost phone into an inconvenience rather than an investigation.

Review the list after any change of phone, carrier or operating system version. Migrations are when settings reset quietly, and a restored backup can bring an app back without the biometric gate you had enabled.

The post Wallet Security on Mobile appeared first on FogChain.

That sounds like a corporate feature, but the same logic solves a personal problem: a single key is a single point of failure, and a multisig wallet turns that into a threshold. This guide covers thresholds, costs, setup and the failure modes that make people give up on it.

• A threshold, not a committee. A 2-of-3 needs any two keys, so no single person and no single device can move funds alone.
• Spares are part of the design. Choose the threshold by how many keys you can afford to lose, not by how many people you want involved.
• Costs are coordination and fees. Each spend needs several signatures, which adds latency, transaction size and a workflow you must practise.
• Recovery is the hard part. Losing enough keys below the threshold means the funds stay put permanently, with no support line to call.

What a multisig wallet changes

It changes who can spend, and makes that answer structural. With a single-key wallet, possession of the key is authority. With a multisig, authority is a set of approvals that satisfies a rule visible before anything goes wrong.

The security benefit is not that keys become harder to steal. It is that one stolen key, or one lost device, no longer ends the arrangement.

Shared control without shared trust

Two business partners can hold an account that neither can drain. A person can split keys between a home device, a safe, and a relative, so a burglary is inconvenient rather than final. In both cases each signer sees the same transaction and approves it independently.

That last detail matters. Each signer’s device displays the destination and amount, so one compromised machine cannot quietly redirect a payment that the others approve blind.

No single point of failure

Single-key setups concentrate every risk in one object. A multisig spreads that object across locations and people, and the threshold determines how much of it can disappear before access does.

The trade is that you now have a system to operate. Keys must be created separately, stored separately, and tested together at least once, or the apparent redundancy is theoretical.

What m-of-n means in practice

In an m-of-n scheme, n keys exist and any m of them can authorise a spend. The pair is usually written as 2-of-3 or 3-of-5, and the second number is the one people get wrong: adding keys adds administration, not safety, beyond the tolerance you actually need.

Worked example: choosing 3-of-5

Suppose you want to survive the loss of two keys, which covers a fire at one location and a forgotten passphrase at another. If two keys can be lost, at least three must remain, so the threshold is 3 and the total is 5: three signing keys plus two spares.

Now check the arithmetic from the other side. With 5 keys and a threshold of 3, there are ten distinct groups of three keys that can each authorise a spend. Each group is a valid path to the funds and also a set of devices a thief would need to collect: five keys, ten ways to spend, two losses tolerated.

Compare 2-of-3. Three keys, three possible signing pairs, one loss tolerated. Compare 4-of-7. Seven keys, thirty-five signing groups, three losses tolerated, and four devices to coordinate on every payment. The threshold grows faster than the convenience does.

Notice that 2-of-2 is strictly worse than 2-of-3 for the same number of required signatures. The third key costs one more backup and removes a fatal failure mode, which is why the extra spare is usually worth it.

A multisig does not make theft impossible; it makes theft require a coincidence, and makes loss require a second coincidence before it becomes permanent.

Where the costs show up

The costs are real but mostly operational. A multisig spend is not one approval, it is a small workflow, and each part of that workflow has a price in time, fees or attention.

Fees and transaction size

On account-based chains, a spend from a multisig contract often costs more than a plain transfer because the transaction carries several signatures and the contract verifies each one. On chains with native multisig accounts, the fee premium is smaller but the transaction is still larger. Exact numbers depend on the chain, the threshold and current network conditions; measure with a small test spend rather than estimating from a blog post.

Latency and coordination

Every additional signature is a round trip. If each signer needs to fetch a hardware device, unlock it, read the screen and confirm, a three-signature spend can take several minutes of focused attention. That is fine for a monthly transfer and painful during a market move, which is why many people keep a small hot balance outside the multisig.

Recovery complexity

Recovery is where multisig setups quietly fail. If the software that created the account is discontinued, or the descriptor describing the key set is lost, the keys alone may not reconstruct a spendable account. Store the account description, not just the seed phrases, and confirm a restore before the balance is large.

How to set up a multisig wallet

Set it up in this order. Each step is cheap before the account holds value and expensive after.

1. Decide the tolerance first. Count the failures you want to survive, then derive n and m from that number rather than from a template.
2. Generate each key separately. Use a distinct device per key, ideally from different manufacturers, so one firmware flaw cannot affect the whole set.
3. Record each seed phrase independently. Separate storage per key, with no location holding two.
4. Create the account and save its descriptor. The address alone is not enough; the description of which keys and which threshold define the account is what makes recovery possible.
5. Test a small spend and one recovery. Send a trivial amount, approve it with the full threshold, then rebuild the account from the descriptor on a clean device.
6. Document the process for the other signers. A co-signer who cannot operate the device is a key you do not have.
7. Review signers yearly. Remove anyone who has moved on, and replace hardware that no longer receives updates.

Step five is the one people skip. A multisig that has never completed a spend and a restore is a design, not a working arrangement, and the difference tends to appear at the worst possible time.

The post Multi-Signature Wallets Explained Simply appeared first on FogChain.

Good hygiene around a crypto address book is not about neatness. It is about making sure that every saved entry points at an address you verified once, under calm conditions, and that no entry survives a change you did not notice. This guide covers what the list actually stores, how entries drift out of date, and how to audit it in a few minutes a month.

• Saved means unverified. A stored address is trusted by default on every later send, so the first save is the only moment you really look at it.
• Labels are the weak link. A label that says a name is a claim, not proof, and lookalike labels are how wrong addresses get selected.
• Chains are not interchangeable. An address that works on one network can be meaningless or dangerous on another, especially across EVM chains and newer formats.
• Deletion is part of hygiene. Old entries, test addresses and duplicates create the exact ambiguity an attacker wants.

What a crypto address book holds

It holds a mapping from a human label to a machine string, sometimes with a network attached. The label is for you; the string is what the network reads. Only one of those has any authority.

That asymmetry explains most address book incidents. People check the label because it is readable, and the label is the part an attacker can influence.

Labels, networks and notes

A useful entry carries the address, the network it belongs to, and a note about why it exists, such as which exchange account or which invoice it pays. Without the network field, a withdrawal intended for one chain can be sent on another and arrive nowhere.

Keep labels boring and specific. A label like “Savings” tells you nothing about whether the address is yours; “Savings, hardware wallet, verified 2026-03” tells you what to check.

What the list does not verify

An address book does not confirm that an address belongs to the person you think. It records what you typed or pasted once. If that paste was already wrong, the error is now permanent and pre-approved.

It also does not update. If a counterparty rotates addresses, which some services do per deposit, the saved entry keeps pointing at the old one and funds may still arrive but under a different account, or not at all.

Why saved addresses go wrong

Addresses go wrong in three ways: they were wrong on arrival, they were replaced later, or they were never the right kind of address for the network. Each has a different tell.

Lookalike addresses and clipboard swaps

Some addresses are generated to share the first and last few characters with a target, which is enough to pass a glance at a truncated display. The middle differs, and the middle is what the network uses. Malware that rewrites the clipboard does the same thing at the moment of pasting.

The defence is mechanical. Never approve a send by comparing only the visible ends. Compare the full string, or use a checksummed display where available, and prefer scanning a code to pasting text.

Stale entries and changed counterparties

Services change deposit addresses, teams change treasury wallets, and people change devices. A saved entry from two years ago may still be valid but no longer the address the other side monitors, which turns a correct-looking send into a support ticket.

Re-confirm any address used for a large transfer on a channel you already trust, not on the channel that gave you the address. A message containing an address is not a verification of that address.

Cross-chain collisions

The same string can be valid on several networks, and sending on the wrong one is a common and often irreversible mistake. Some formats look identical across chains; others differ by a single prefix character that is easy to miss at small sizes.

A saved address is a decision you made once and then stopped thinking about, which is precisely why it deserves an annual review.

Verification methods compared

Verification methods differ in how much of the string you actually compare, and in how well they survive a hostile clipboard or a hurried tap.

The strongest routine combines two rows: scan or paste, then verify the full string against a source you trust, then send a small test amount the first time. No single method covers both a swapped clipboard and an address that was wrong to begin with.

A monthly clean-up for your crypto address book

Run this while nothing is pending. Auditing is easier when you are not also trying to send something.

1. Export or screenshot the list. Reading it outside the send flow removes the temptation to fix things mid-transaction.
2. Delete test and duplicate entries. Anything labelled “test”, “temp” or a near-copy of another label goes first.
3. Re-verify each remaining entry you still use. Compare against the source that originally provided it, not against the label.
4. Add the network to every entry. If the wallet supports per-network addresses, use them so a wrong-chain send fails at the interface instead of on the network.
5. Retire counterparties you no longer deal with. A dormant entry is still selectable in a hurry.
6. Note the audit date. A dated list tells you which entries were checked after the last change of device or service.
7. Keep a small allowlist. If the wallet supports it, restrict sends to saved entries so a pasted address cannot bypass the list.

Expect the list to shrink. Most address books accumulate entries that were used once, and a list of twelve verified entries is safer than a list of sixty that nobody has read since they were added.

The post Address Book Hygiene appeared first on FogChain.

That invisibility is exactly why the habit matters. A contract you approved a year ago can still move that token today, and most people have no idea how many standing permissions their address has granted. Learning to revoke token approvals on a schedule turns an unexamined exposure into a known, bounded list.

• An approval is a standing permission. It survives the session, the app and often the project, until you or the contract removes it.
• Unlimited approvals are the default risk. Many interfaces ask for an unlimited allowance, which converts a one-time deposit into permanent access to that token.
• Revoking costs a fee. Each revocation is an on-chain transaction, so decide what is worth revoking rather than clearing everything.
• A monthly habit beats a yearly panic. Reviewing often keeps the list short enough to read, which is what makes the review useful.

What an approval actually grants

It grants a specific contract permission to move a specific token from your address, up to an amount, without further approval from you. The permission sits in the token contract’s state, not in the app, which is why uninstalling anything does not remove it.

That distinction is the source of most confusion. Deleting an app, disconnecting a wallet or clearing a site’s session removes your interface to the permission, not the permission itself.

Allowances: exact versus unlimited

A token allowance is a number. Approve 100 units and the contract can move 100; approve the maximum value the type allows and it can move everything, forever, until you change it. Many interfaces default to the maximum because it saves a transaction on the next deposit.

The convenience is real and so is the cost. An unlimited allowance means a compromised contract or a bug in its logic can drain that token from every approving address, and the exposure persists long after the app stops being used.

Operator approvals for NFTs

NFT markets often ask for an operator approval instead of per-token approval. That grants a contract control over every token in a collection, including ones you acquire later. It is the broadest common permission a retail user grants, and it is usually granted with one tap.

Permit-style signatures are a third form. They are signed messages rather than transactions, so they cost no fee at signing time and do not appear as a transaction in your history, which makes them easy to forget entirely.

The dangerous approval is not the one you remember granting; it is the one from a project you stopped using two years ago.

Why a routine to revoke token approvals beats a one-off clean-up

Because the list regrows. Every new protocol, every new pool and every new marketplace adds entries, and a clean-up performed once a year faces a list too long to read carefully.

A monthly review keeps the list at a size where each entry can be judged individually. It also catches the approvals you granted while distracted, which are the ones most likely to be unnecessary.

What changes month to month

Projects get abandoned, contracts get upgraded, and interfaces get rebuilt. An approval that was reasonable when the protocol was active can become an orphaned permission with nobody watching the contract.

Your own behaviour changes too. A wallet used for testing on a new chain accumulates approvals you would never grant from your main address, which is why the cheapest time to revoke token approvals is the moment the project stops being interesting.

Approval types: what revoking token approvals involves

Different approval types carry different exposure and different revocation mechanics. Knowing which is which tells you what to prioritise.

That last row is the uncomfortable one. Not every permission can be undone with a revoke button, and a signed permit may be spendable until it expires or is used. The cheapest moment to review a permission is before granting it, not after.

A monthly review in seven steps

Set a recurring reminder, pick a quiet moment, and work through the list in one sitting. The whole process usually takes less time than the transaction confirmations it produces.

1. Use a dedicated approval checker. Read the permissions from a tool that queries the token contracts directly rather than trusting a dashboard summary.
2. Sort by value at risk. Start with the largest balances and the unlimited allowances, since those carry the most exposure per entry.
3. Identify what you still use. An approval tied to a protocol you interact with weekly can stay; anything untouched for months goes on the revoke list.
4. Revoke in small batches. Each revocation is a separate transaction with its own fee, so clear the high-priority entries first and stop if fees spike.
5. Confirm each revocation on-chain. Wait for the transaction to confirm and re-read the allowance; a rejected or dropped transaction leaves the permission in place.
6. Review signatures separately. Permits and off-chain approvals do not appear in a transaction list, so check them in a tool that tracks signed messages.
7. Record the date and the remaining list. A short note of what you kept and why makes next month’s review a comparison rather than a fresh investigation.

Expect the first pass to be long and later ones to be short. If the monthly list keeps growing, the problem is at the granting stage: choose exact allowances where the interface allows it, and decline operator approvals for collections you are not actively trading.

The post Revoking Approvals: A Monthly Habit appeared first on FogChain.