The signing keys are
already on the chain.

Bitcoin, Ethereum and Solana all authorise transactions with elliptic-curve keys that a future quantum computer can reverse — and every public key ever revealed on-chain is permanent, copyable, and one day forgeable. Q-Stream adds a quantum-safe authentication and encryption layer across the wallet and the chain, built on single-use, information-theoretic keys that no later computer can unwind.

The headline

What the three major chains expose today — and what a Q-Stream layer changes.
Schemes at risk
ECDSA · Schnorr
Ed25519
Every signature scheme on BTC, ETH and SOL rests on elliptic-curve discrete-log — all reversible by Shor’s algorithm.
BTC in exposed addresses
~25% est.
Coins held in reused or pay-to-public-key addresses where the public key is already visible on-chain.1
Confidentiality model
Information
-theoretic
Immune to “harvest-now, decrypt-later” — captured ciphertext stays unreadable regardless of future compute.
L1 consensus change
None on ETH / SOL
Adopts through smart accounts and on-chain programs that already exist — no fork of the base layer required.
§1

The exposure

A blockchain’s security comes down to one assumption: only the holder of a private key can produce a valid signature. That assumption rests entirely on elliptic-curve cryptography being hard to reverse.

It is hard for today’s computers. It is not hard for a sufficiently large quantum computer. Shor’s algorithm solves the elliptic-curve discrete-logarithm problem in polynomial time, which means it can recover a private key directly from a public key. That single fact applies equally to Bitcoin and Ethereum’s ECDSA, Bitcoin’s newer Schnorr signatures, and Solana’s Ed25519 — they all stand on the same curve mathematics.

The threat does not wait for the hardware to arrive. It is called “harvest now, decrypt later.” A public key, once revealed on-chain, is recorded forever. An adversary can copy every exposed key today and forge its owner’s signatures the day a capable machine exists. On a blockchain you cannot simply rotate a compromised key after the fact — the history is immutable, and on some chains the address is the public key.

Hashes buy time, not safety. Bitcoin and Ethereum often keep a public key behind a hash until you first spend, and Grover’s algorithm only weakens hashes quadratically rather than breaking them. That delays exposure — it does not remove it. The moment you transact, or reuse an address, the key is in the open and permanently harvestable.

§2

What Q-Stream adds

Q-Stream is a cryptographic protocol whose confidentiality is information-theoretic — its security does not rest on any problem being hard to compute, so no future computer, quantum or otherwise, can reverse it. It protects digital assets across two layers: the wallet, where keys are held and transactions are authorised, and the chain, where authority is verified and confidential data is exchanged.

Four building blocks do the work:

Q-Block

A wallet-unique, high-entropy block of key material — the shared root from which every single-use key is drawn.

Path Derivation Key

A per-message rotating key (PDK). Every transaction is signed under a fresh, single-use key that is never repeated.

Provisioning

How the wallet and the verifier come to share the same Q-Block, and how it is refreshed before its key material runs out.

Q-Path

A zero-knowledge proof of authority. Proves you can spend without ever revealing a key that Shor’s algorithm could later break.

Together these mean a wallet can authorise and prove ownership without putting a breakable key on the chain, and any data it sends is encrypted under keys that capture cannot unlock — now or in the quantum era.

WALLET LAYER Key custody Tx authorisation seed encrypted info-theoretic at rest Q-STREAM Q-Block PDK Provision Q-Path single-use key per message 8-byte tag · ZK proof of authority no breakable key revealed ON-CHAIN LAYER BBitcoinTaproot script · vault · soft-fork EEthereumsmart account · ERC-4337 / 7702 SSolanaon-chain program verification
Two layers, one protocol   The wallet holds and authorises; Q-Stream derives a single-use key and a zero-knowledge proof of authority; the chain verifies it through machinery each network already supports. The breakable elliptic-curve key never has to appear.
§3

Inside the Q-Block

The root of every key — a block of true randomness, used once and never transmitted.

The Q-Block is the single source of all Q-Stream key material: a large block of genuinely random bits, generated once from a high-quality entropy source — in practice a quantum random number generator — and held privately by the wallet. Every single-use key the wallet will ever need is drawn from it. The block itself is never sent over any channel, and no region of it is ever reused.

Its security is information-theoretic, which means it rests on no problem being hard to compute. The foundation is Shannon’s result on perfect secrecy: if a message is combined with a truly random key that is used once and is at least as long as the message, the result reveals nothing about the message — to any adversary, with any amount of computing power, classical or quantum.

Perfect secrecy (Shannon, 1949)c = m ⊕ k   with  k ←$ QB,  |k| = |m|,  k used once ⇒  Pr[ m | c ] = Pr[ m ] the ciphertext is statistically independent of the message — there is no problem to “break”, now or in the quantum era.
Entropy source
QRNG
Bias- and run-length-validated before use.
Working block
1,024-bit illustrative
Many keys drawn before refresh; production blocks are far larger.
Derived state
256-bit
The active secret held between messages.
Worked example — one byte, perfect secrecy

Take one message byte and one key byte drawn from the Q-Block.

message  m = 'A'   = 0x41 = 0100 0001 key      k = 0x9F  = 1001 1111  (one byte of the Q-Block, used once) cipher   c = m ⊕ k = 0xDE = 1101 1110

Knowing only c = 0xDE, every one of the 256 possible plaintext bytes is equally likely — each corresponds to exactly one key byte, and all key bytes were equally probable. The ciphertext leaks nothing. Reuse that key byte for a second message, though, and the guarantee is gone — which is what the next mechanism prevents.

§4

The path-derived key

A fresh, single-use key for every message — and never the same one twice.

A wallet does not slice the Q-Block into fixed pieces. It walks a path through it. For each message a per-message path descriptor selects a fresh region of the block, producing a single-use key — the path-derived key (PDK). The path always advances, so the same key is never produced twice.

Both ends that share the Q-Block and the same path rule derive the identical key independently; nothing about the key crosses the wire. Choosing a traversal that visits each position once before any repeat — the same property a de Bruijn sequence has — keeps every key unique while using the block efficiently.

Per-message key derivationk_p = Φ(QB, p),   p = path(nonce, ctx) distinct p  ⇒  disjoint regions of QB  ⇒  each k_p used once forward secrecy:  k_p reveals nothing about k_p′ for p ≠ p′

Single-use is the whole point. The perfect-secrecy result above, and the authentication below, hold only while each key is used exactly once. The path rule’s job is to guarantee that.

To authorise a transaction, the wallet authenticates it with a one-time message authentication code in the Carter–Wegman style: a hash drawn from a universal family (keyed from part of the key) is masked by a one-time pad (the rest of the key). An attacker’s chance of forging a valid tag is bounded by a tiny constant that does not depend on computing power.

One-time authentication (Carter–Wegman)tag t = h_a(m) ⊕ b,   (a, b) drawn from k_p,  h_a from a universal family Pr[ forgery ] ≤ ε ≈ 2^(−|t|) e.g. |t| = 64 bits ⇒ ε ≈ 2^(−64), against an unbounded adversary
Worked example — two messages, two paths
Q-Block bytes  (index:value) 0:3A  1:9F  2:C1  3:08  4:55  5:E2  6:7B  7:14  8:A0  9:6D ... message 1 → path p1 = [3,4,5]  →  k_p1 = 08 55 E2 message 2 → path p2 = [6,7,8]  →  k_p2 = 7B 14 A0

The paths are disjoint, so k_p1 and k_p2 share no bytes. Capturing the first transaction tells an attacker nothing about the key behind the second — per-message forward secrecy, by construction.

§5

Proving authority without a key

A zero-knowledge proof that you can spend — with no breakable key revealed.

Signing normally means publishing something only your key could produce — which means the key, or a value derived from it, ends up on a public, permanent ledger. Q-Stream takes a different route. Instead of signing with a breakable key, the wallet proves that it knows a secret path through the Q-Block, without revealing the path. This is the protocol’s zero-knowledge proof of authority (Q-Path).

It follows the classic three-move structure of an interactive proof — commit, challenge, response:

  1. Commit. The wallet picks fresh randomness and sends a commitment to its secret path. The commitment hides the path but binds the wallet to it.
  2. Challenge. The verifier — a smart account or an on-chain program — replies with a random challenge.
  3. Respond. The wallet returns a response computed from the path, the randomness and the challenge. The verifier accepts only if the response is consistent with the commitment and the challenge.
Zero-knowledge proof of authority (sigma form)P → V :  C = Commit(π, r)     // π = secret path, r = fresh randomness V → P :  e ←$ challenges P → V :  z = Respond(π, r, e) V     :  accept  ⇔  Check(C, e, z)

The secret is protected by path ambiguity: for the values the verifier sees, an enormous number of different paths are equally consistent. Observing valid proofs — even many of them — does not narrow down which path is the real one. Authority is established without ever exposing a value a quantum computer could reverse.

Worked example — why the proof leaks nothing
A public commitment is consistent with, among many others:    path π_a = [2,5,9,3]    path π_b = [7,1,4,8]    path π_c = [0,6,2,5]  … (exponentially many) verifier confirms:  "a valid path was known" verifier cannot tell: which path — π_a, π_b, π_c, or another

Every accepted proof is equally explainable by a huge set of paths, so the transcript carries no information about the wallet’s actual secret. On-chain, the verifier runs only the cheap Check(C, e, z) step — and no curve key is ever published.

§6

Provisioning the key material

Sharing the Q-Block once, and refreshing it before it runs out.

Single-use, information-theoretic keys only work if both ends hold the same Q-Block and never exhaust it. Provisioning is the process that makes that true: generate the block, deliver it once, and refresh it before its key material is used up. It is the operational heart of the system.

The capacity of a block is simple to reason about: a block of B bytes supports about B / L authenticated messages, where L is the key material consumed per message.

Capacity before refreshmessages ≈ floor( B / L ) example:  B = 1 MB block,  L = 64 bytes/message          ⇒ ≈ 16,384 authenticated transactions before refresh production deployments size B to the expected traffic between refreshes.
§7

How it compares to post-quantum cryptography

Lattice PQC swaps one hard problem for another; Q-Stream removes the dependency — at a different operational cost.

Post-quantum schemes such as ML-KEM (key exchange), ML-DSA / Dilithium and Falcon (signatures) are the right answer where no key material can be pre-shared: they replace the elliptic-curve problem with a lattice problem believed to resist quantum attack. They remain computationally secure — secure under the belief that the lattice problem is hard. Q-Stream removes the hard-problem dependency altogether, in exchange for needing a pre-shared, refreshed Q-Block. The practical consequences show up on the wire and in the processor.

Object on the wire — bytes · lower is better ML-DSA-44 sig ML-KEM-768 ct Falcon-512 sig Q-Stream tag 2,420 B 1,088 B 666 B 8 B
Object on the wire   A Q-Stream authentication tag is a few bytes; even Falcon, the most compact post-quantum signature, is roughly eighty times larger, and a Dilithium signature is larger still. On constrained or high-fee chains, that size difference is felt directly in cost.
Recurrent compute — cycles per operation, log scale · lower is better 10K100K1M10M ML-DSA-44 sign ML-KEM-768 encaps Q-Stream derive+tag 3,943,121 658,754 ~20,192 Q-Stream modelled · PQC from published Cortex-M4 benchmarks
Recurrent compute   The work done per message. Lattice operations run into the hundreds of thousands or millions of cycles; the modelled Q-Stream path-and-tag step is a small fraction of that. Falcon’s signing adds floating-point Gaussian sampling, also in the millions of cycles.
Persistent secret material — bytes · lower is better ML-DSA-44 sk ML-KEM-768 sk Falcon-512 sk Q-Stream state 2,560 B 2,400 B 1,281 B 32 B *
Persistent secret material   The standing secret each side stores. Q-Stream’s active state is small — * it additionally holds a shared Q-Block reservoir, amortised across many messages, which the PQC key sizes do not require.

The trade is explicit. PQC needs nothing shared in advance but ships kilobyte-scale objects and runs heavy lattice arithmetic on every operation. Q-Stream ships an eight-byte tag and does little more than a table walk and a one-time hash — but it must hold and refresh a shared Q-Block. For wallets and devices that can be provisioned once and refreshed, that is a favourable exchange; where no provisioning is possible, lattice PQC remains the appropriate tool.

Sources. PQC object and key sizes are the standardized values: ML-KEM-768 ciphertext 1,088 B and secret key 2,400 B (FIPS 203); ML-DSA-44 signature 2,420 B and secret key 2,560 B (FIPS 204); Falcon-512 signature ~666 B (typical) and secret key ~1,281 B. Cycle figures for ML-KEM and ML-DSA are representative published Cortex-M4 benchmarks; Q-Stream figures are modelled from the protocol’s single-use-key design and are illustrative. Worked examples throughout use small illustrative parameters; production parameters are larger.
§8

Per chain

The same protocol meets three very different networks. Each has its own scheme, its own exposure, and its own route in.
B
BitcoinBTC
SignatureECDSA + Schnorr
Curvesecp256k1
Key exposurehidden behind a hash until you spend; ~25% est. already revealed
Q-Stream routeoff-chain authorisation, Taproot script-path locks and co-signing vaults today; native verification via a future soft fork
E
EthereumETH + EVM
SignatureECDSA
Curvesecp256k1
Key exposurepublic key recoverable from any transaction you sign
Q-Stream routestrongest near-term — smart accounts (ERC-4337, EIP-7702) verify a Q-Stream proof in contract logic, no base-layer fork
S
SolanaSOL
SignatureEd25519
CurveCurve25519
Key exposurethe address is the public key — exposed from the moment an account exists
Q-Stream routean on-chain program verifies the proof; the small 8-byte footprint suits high throughput and low fees

Stated plainly. Ethereum and Solana can verify a Q-Stream proof on-chain today, through account abstraction and programs that already exist. Bitcoin’s base layer cannot — native verification there would need a soft fork. Until then Q-Stream protects Bitcoin holdings at the custody and authorisation layer and through Taproot script paths.

§9

The wallet layer

Encryption and authentication where the keys actually live.

Most asset loss is not a broken curve — it is a stolen seed, a reused key, or a signed transaction an attacker captured and replayed. The wallet layer closes those gaps first, and is quantum-safe by construction.

How it authenticates a transaction

  1. The wallet holds a Q-Block — high-entropy key material unique to that wallet — encrypted at rest under an information-theoretic key, so a stolen device or backup yields nothing usable.
  2. To authorise a transaction, the wallet derives a single-use Path Derivation Key from the Q-Block and the transaction’s path. The key is used once and never repeated.
  3. It produces a compact 8-byte authentication tag over the transaction, and, where the chain supports it, a Q-Path zero-knowledge proof that it holds spending authority — without revealing the underlying key.
  4. Because each authorisation uses a fresh key, capturing one signed message exposes only that one message — never the wallet, and never future transactions.
§10

The on-chain layer

Encryption and authentication that the network itself can verify.

Authorisation only counts if the chain accepts it. The on-chain layer is where Q-Stream’s proof is checked and where confidential data is carried — using verification machinery each network already provides.

Authentication

A smart account on Ethereum (ERC-4337 or EIP-7702) or a program on Solana contains the verification logic: it accepts a transaction only when the accompanying Q-Stream tag and Q-Path proof check out. The account’s authority is bound to the Q-Block, not to a raw elliptic-curve key — so even a fully exposed on-chain identity gives an attacker nothing to forge against. On Bitcoin, the same intent is expressed through Taproot script paths and co-signing vaults until a soft fork allows native verification.

Encryption

Transaction memos, off-chain channel messages, and any confidential metadata are encrypted under the same single-use keys. They are readable only by the intended holder, and they stay unreadable even if recorded and stored against a future quantum computer. A captured message exposes one message — never the channel.

Carried across:Smart-account authProgram verificationConfidential memosOff-chain channels
§11

The algorithms, working

Not a description — the real operations, running in your browser.

Everything above is easy to assert and hard to believe without seeing it. So the four building blocks are implemented here and run live: the Q-Block, the path-derived single-use key, the one-time authentication tag, and the proof of authority. The numbers shown are produced on this page by the same code — nothing is pre-baked or faked.

What this is, honestly. These are faithful, working models of the mechanisms at demonstration scale: a 256-byte Q-Block instead of a large quantum-random buffer, and 64-bit tags so the maths is legible. The one-time MAC is a genuine Carter–Wegman construction whose security is information-theoretic; the proof is a real hash-based commit–challenge–response. Hashing uses SHA-256 purely as a public mixing function — the security of the one-time tier comes from single-use key material, not from any hash being hard to reverse. Production parameters and the fully-blinded Q-Path proof differ; the structure you see here is the structure that ships.

Read the full security analysis & proofs → — preconditions, worked examples, formal definitions, and theorems with proofs for both operations, written to be checked independently.

Building block 1 · Q-Block → key

A fresh single-use key, walked out of the Q-Block

The wallet holds one private block of true randomness. For each transaction it walks a secret path through the block, reading out a single-use path-derived key (PDK). The path always advances, so no key is ever produced twice — and a second party holding the same block and path rule derives the identical key with nothing crossing the wire.

Q-Block (256 bytes — highlighted cells are this transaction’s path)
current pathprevious path (already spent)
Wallet label / pathwallet-demo-0001 · tx#1 · cursor 0
Path indices (this transaction)221,68,247,174,91,29,110,78,15,169,212,17,147,67,31,133
Path-derived key (single-use)b3589bae7909b90835dc10f4d80de27e
Building block 2 · one-time MAC

Authenticating a transaction — and catching tampering & replay

What the tag proves — and who can check it

The 8-byte tag is a symmetric authenticator: it is produced from the transaction and from one-time key material drawn from the Q-Block, and checking it requires that same key material. So the party that verifies the tag is one that shares the Q-Block — your second device, a custody or co-signing service, a payment counterparty — not the public blockchain, which holds no secret of yours. This is the wallet-layer check, and it is where most real-world theft is actually stopped: a transaction altered in flight, or a correctly-signed one captured and re-submitted later.

It stops them for two structural reasons. First, the tag is computed over every byte of the transaction, so changing any field — the amount, the destination — yields a completely unrelated tag; there is no “close enough.” Second, the key is consumed once and the wallet’s path then advances, so a recorded (transaction, tag) pair cannot be replayed: the next valid tag is computed from key material the attacker has never seen and cannot derive.

And the strength here rests on nothing being hard to compute. The masking value mixed into the tag is uniformly random and used exactly once, so an adversary — with any amount of computing power, classical or quantum — has at best about a one-in-261 chance of guessing a valid tag for a transaction they did not author. That is information-theoretic security: it is a property of the randomness, not a bet on a problem staying difficult.

The single-use key produces a compact 8-byte tag over the transaction using a Carter–Wegman one-time MAC. Forging a tag without the key succeeds with probability about one in 261 — not because anything is hard to compute, but because the masking key is random and used once. Edit the transaction and watch the tag move; try to tamper or replay and watch it be rejected.

Transaction (editable)
Universal-hash key r / one-time pad a (from the PDK)r = 0x13589bae7909b90d   a = 0x15dc10f4d80de27f
Authentication tag1f6414fcffde6b49
Building block 3 · proof of authority

Proving the right to spend — without revealing the key

How a public chain verifies this — holding no secret of its own

This is the part worth understanding properly, because it is not obvious how an untrusting public ledger, which never sees your Q-Block, can decide that a spend is authorised. It works because authority is anchored in public, one-way commitments, and the proof is welded to the exact transaction.

At provisioning the account publishes a set of anchors, each one a hash aₕ = H(sₕ) of a secret sₕ that is itself derived from the Q-Block. Because a hash is one-way, the anchors give away nothing about the secrets — they can sit on an immutable ledger forever in perfect safety. (Contrast an ordinary elliptic-curve public key, which a quantum computer can run backwards into the private key. There is no such reversible object here.)

To authorise a transaction T, the wallet first computes a challenge c = H(T). Because the challenge is the hash of the transaction itself, the resulting proof is bound to T alone — it cannot be peeled off and reused on a different transaction. That challenge then deterministically selects a subset of the anchors, and the wallet responds by revealing exactly the secrets for that subset.

Now the verification is something any node can do with public data only: recompute c = H(T), recompute which anchors c selects, and check that each revealed secret hashes to its published anchor — H(sₕ) = aₕ. If every check passes, the spender has demonstrated possession of the Q-Block-derived secrets the account was built from — the right to spend — and the chain has confirmed it while holding no secret and trusting no one. A forger has no way through: to pass they would need to produce preimages of specific 256-bit anchors that the transaction itself chose, and inverting a hash is infeasible. This is the one place the on-chain proof relies on a computational assumption — hash preimage-resistance — and it is precisely the assumption that survives quantum attack (Grover’s algorithm only halves the exponent, leaving 256-bit anchors at about 128-bit security).

Two honest footnotes. The live demo above reveals the selected secrets directly — a transaction-bound, hash-based commit–challenge–response, in the family of hash-based signatures. The production Q-Path additionally blinds each response so the revealed values themselves leak nothing, making the proof fully zero-knowledge; the reason the chain can verify is identical either way. And because each authorisation discloses part of the secret set, the wallet rotates to fresh anchors as its path advances through the Q-Block — so no secret is ever exposed twice, and every proof stays one-time.

At provisioning the wallet publishes anchors (hashes of secrets bound to the Q-Block) — that is the on-chain identity. To authorise a transaction it answers a challenge derived from the transaction by revealing only the secrets that challenge selects. A verifier checks them against the anchors. Someone without the Q-Block can only guess, and is caught.

Public anchor #0 (published once, at provisioning)c08e6f6064806fbee93ad46213ad3f86e8243ec036c14b3e1d46c9a501f69394
Challenge = SHA-256(transaction)9cf279de7bbc788865e206b73411df4a…
Secrets the challenge selects (only these are revealed)0, 1, 5, 11, 18, 19, 30, 31

What the tag covers, and where it is checked

The same three building blocks apply to every chain. What differs is where the proof is verified and how much of the transaction the tag binds. Each card below shows a representative transaction and the real 8-byte tag the demo key produces over it.

Bitcoin

Custody & Taproot today

Tag binds inputs, outputs and amounts; enforced at the wallet, multisig vault and Taproot script path. Native consensus checking awaits a soft fork.

tag = 0364198500b55095 verified: custody / Taproot
Ethereum

Smart account, on-chain

An ERC-4337 / EIP-7702 account verifies the tag and Q-Path proof in-contract before execution. Authority is bound to the Q-Block, not a raw EC key.

tag = 096e432942cc3770 verified: on-chain
Solana

Program, on-chain

A verifier program accepts the instruction only when the tag and proof check out against the account’s anchored authority — checked by the network itself.

tag = 143610244ab44367 verified: on-chain
Reading the cards. The tags are genuinely computed by the demo wallet key over each transaction; change the wallet (button above) and they would all change. Ethereum and Solana can verify the proof in account-abstraction logic or a program today; Bitcoin enforces the same intent at the custody and Taproot layer until native verification lands.
§12

The comparison

Q-Stream as a protection layer against the schemes the three chains rely on today.
Property ECDSAsecp256k1 SchnorrBIP-340 Ed25519Curve25519 Q-Streamprotection layer Q-Stream advantage
Used byBTC, ETHBTC (Taproot)Solanalayer across all threeOne model, every chain
Security rests onEC discrete-logEC discrete-logEC discrete-loginformation-theoreticNo hard problem to break
Shor’s algorithmBrokenBrokenBrokenImmuneQuantum-safe by construction
Harvest-now-decrypt-laterVulnerableVulnerableVulnerableImmuneNothing to harvest
Public key on-chainOn first spendOn first spendFrom creationNever requiredNo forgeable target left
Per-message forward secrecyNoNoNoYesCompromise can’t cascade
Capture exposureKey → all fundsKey → all fundsKey → all fundsOne messageBlast radius of one
Authentication overhead~71–72 B sig64 B sig64 B sig8 B tag+ amortized Q-BlockSmaller on-wire footprint
Reading the table. Q-Stream is a protection layer, not a drop-in replacement for an on-chain signature primitive. The point is not to out-sign ECDSA on today’s hardware — it is to remove the elliptic-curve dependency that all three schemes share, and the permanent, harvestable exposure that follows from putting a breakable key on an immutable ledger.
§13

Honest scope

What this does, and where the limits sit.

The takeaway. The keys are already on the chain, and on an immutable ledger you cannot take them back. Q-Stream gives a wallet a way to authorise and prove ownership without ever exposing a key a quantum computer could break — across Bitcoin, Ethereum and Solana, through machinery the chains already understand.

Notes. 1 The ~25% figure is a widely-cited industry estimate of the share of bitcoin held in addresses with exposed public keys (pay-to-public-key outputs and reused addresses); exact figures vary by methodology and over time and should be read as indicative. Signature sizes are typical encoded lengths: ECDSA ~71–72 bytes (DER), Schnorr and Ed25519 64 bytes. Q-Stream figures reflect the protocol’s stated single-use-key model and 8-byte authentication tag. This document is an architectural use-case overview, not a security audit or investment advice.