Bitcoin: recovery and Lightning
Bitcoin output descriptors: the wallet backup beyond a seed
Keys, derivation paths and spending rules answer different recovery questions.
MASTR · CRYPTO & WEB3
New in the reference library
24 new guides to wallets, Bitcoin, Solana and market mechanics. Follow a reading path or choose a specific question.
Article text and technical graphics are in English. Navigation is available in seven languages.
07
Bitcoin: recovery and Lightning
6 · Reference guides →08Names, identity and web content
4 · Reference guides →09Solana: from quote to settlement
5 · Reference guides →10Liquidity, prices and pool rules
4 · Reference guides →11Smart accounts and governance
5 · Reference guides →Bitcoin: recovery and Lightning
Bitcoin: recovery and Lightning
Schnorr and MuSig2: several signers, one Bitcoin signature
Compact signatures change what is visible on-chain, not the need for a sound custody policy.
Bitcoin: recovery and Lightning
Bitcoin timelocks: a calendar condition versus a coin’s age
Absolute and relative locks start their clocks in different places.
Bitcoin: recovery and Lightning
Bitcoin coinbase maturity: why a new mining reward cannot move immediately
A consensus waiting period for mining outputs is distinct from ordinary payment confirmations.
Bitcoin: recovery and Lightning
Lightning inbound liquidity: why a funded wallet may still fail to receive
Receiving capacity depends on the direction of channel balances and the available route.
Bitcoin: recovery and Lightning
BOLT 11 invoices: what a Lightning payment request actually says
A signed invoice carries payment conditions; it is neither a reusable bank account nor proof of delivery.
Names, identity and web content
Names, identity and web content
Passkeys and crypto wallets: easier login, a new recovery map
The origin-bound credential, the account’s authority and the backup system need separate inspection.
Names, identity and web content
ENS names: why a reverse record needs a forward check
A readable name improves navigation only when the address relationship is verified.
Names, identity and web content
IPNS: a stable name for content that can change
A signed pointer solves updating, while availability and key custody remain separate jobs.
Names, identity and web content
DNSSEC and HTTPS: two checks behind a wallet website
Authenticated name resolution and encrypted transport do not certify a financial application.
Solana: from quote to settlement
Solana: from quote to settlement
Solana address lookup tables: compressed references, full responsibilities
A shorter transaction encoding does not mean the loaded accounts matter less.
Solana: from quote to settlement
Solana transaction expiry: submitted is not confirmed
A recent blockhash limits validity; a timeout alone does not establish the final outcome.
Solana: from quote to settlement
Solana priority fees: the compute limit is part of the price
Separate the base network fee, prioritisation, Jito tips and application charges.
Solana: from quote to settlement
Jito bundles: ordering, tips and the limits of protection
A preferred submission path is useful infrastructure, not a universal guarantee against adverse execution.
Solana: from quote to settlement
Jupiter quotes: expected output, minimum output and the actual exit
A route quote is a timestamped estimate for a size, not a promise that the last chart price is executable.
Liquidity, prices and pool rules
Liquidity, prices and pool rules
TWAP and VWAP: averages answer different questions
Time weighting, volume weighting and executable liquidity should never be collapsed into one number.
Liquidity, prices and pool rules
Concentrated liquidity: ticks, active capital and fee growth
A pool can hold substantial value while only part of its capital supports the current price.
Liquidity, prices and pool rules
Uniswap v4 hooks: a shared exchange core, different pool behaviour
The hook contract belongs in the explanation of the pool, not in a footnote.
Liquidity, prices and pool rules
Aave health factor: a moving buffer, not a safety rating
Collateral prices, debt growth and configured thresholds determine the liquidation boundary.
Smart accounts and governance
Smart accounts and governance
ERC-7579: wallet modules are part of the authority map
Validators, executors and hooks have different powers inside a modular smart account.
Smart accounts and governance
ERC-6492: signatures from an account that is not deployed yet
An empty address can have a planned contract identity; verification must follow the correct model.
Smart accounts and governance
EIP-6963: choosing between browser wallets without trusting the icon
Provider discovery solves a coordination problem; names and icons remain self-reported.
Smart accounts and governance
Governance checkpoints: whose votes counted, and when?
Delegation, historical voting weight and proposal timing determine more than a current token balance.
Smart accounts and governance
EIP-4788: a beacon root is a commitment, not the whole beacon state
Ethereum exposes a consensus-layer commitment to contracts; the proof and interpretation still need work.