Illustrative transparent transfer · fee is not an output.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
Reviewed 18 September 2026. This guide covers ordinary transparent transactions. UI labels were checked against Litecoin Core v0.21.5.8 source files; menu placement can differ by operating system. are illustrative, not current recommendations. The cover is a diagram of the example or system described in this guide.
Your displays “2 LTC”, but the does not necessarily contain one object worth 2 LTC. That balance could come from two outputs worth 1.2 and 0.8 LTC, twenty small receipts, or hundreds of payouts. Spending the same amount can therefore require different numbers of inputs and different fees.
Understanding , or UTXOs, explains where change goes, why repeated small deposits affect future transactions, and what can actually control. It also helps you avoid a costly misconception: combining everything into one output is not automatically a privacy improvement.
1. A UTXO is an output you have not spent
In a transparent transaction, an output records a value and a spending condition. A later input refers to that output using its previous and output index. Litecoin Core represents this reference as an . The script determines how the output can be spent; the is a convenient representation used when constructing certain scripts. Source: Litecoin Core transaction structures.
Terms that often get confused
Term
Meaning in this guide
UTXO
A transaction output not yet spent
Outpoint
A prior transaction ID plus the index identifying its output
Input
A reference to a prior output, with data needed to satisfy spending rules
Output
Value and a spending condition created by a transaction
Change
A new output returning value to the sender’s wallet
Wallet balance
A view aggregating relevant outputs; spendability depends on context
Coin control
Wallet controls for inspecting and choosing outputs used by a payment
Receiving several payments to one address can create several UTXOs. Conversely, a wallet can control UTXOs associated with many addresses. A 's address balance, the wallet's total balance and the set currently available for spending answer different questions.
For example, a wallet can track a output without possessing the . Another output may be temporarily unavailable under the wallet's , locking or transaction-selection rules. “I can see it” is not sufficient evidence that it can fund the transaction you are composing.
2. Follow one payment, including the change
Suppose you control two transparent outputs: 1.20000000 LTC and 0.80000000 LTC. You want the recipient to receive exactly 1.30000000 LTC. For this illustration, the completed transaction pays a fee of 0.00000418 LTC.
Exact value conservation for an illustrative transparent transfer. The fee is a difference, not a separate output. Open full-size SVG. On a narrow screen, scroll the figure horizontally.
Both selected inputs are consumed in full. The wallet does not trim a piece from one input and leave the old output partially unspent. It creates a new for the remainder. The is the difference between input value and output value; it is not an extra payment output to a generic “miner address”. This input/output model is described in the Bitcoin developer transaction guide and is reflected in Litecoin's transparent transaction structures.
The recipient sees 1.3 LTC, while your spendable balance falls by 1.30000418 LTC. A transaction history that lists the full 2 LTC of inputs has not demonstrated that 2 LTC was paid to somebody else. Check the outputs, identify change cautiously, and separate the transfer amount from the fee.
A wallet normally manages its own change destination. Do not paste an address from an deposit screen into a custom change field simply because it is familiar. Change is part of your payment construction and needs a destination you intend and can use. When using a , review the transaction on its trusted display according to the device's instructions.
3. Why input count affects fees
A transaction containing more inputs usually requires more serialized data and signatures. For transactions, is the transaction's weight divided by four, rounded up. A byte and a virtual byte are therefore not interchangeable terms. Source: BIP 141 size definitions.
To make the relationship visible, use this approximate model for standard native SegWit inputs and outputs:
Estimated vbytes = ceil(10.5 + 68 × inputs + 31 × outputs)
Fee in litoshi = estimated vbytes × fee rate in litoshi/vB
Fee in LTC = fee in litoshi ÷ 100,000,000
The model assumes small input/output counts with ordinary compact-size fields and approximately 68 virtual bytes per input. Actual signatures can alter the exact weight. It is an educational estimate, not a promise about your wallet's final signed transaction. , legacy scripts, different output types and MWEB require different calculations.
Approximate native SegWit model; two outputs and 2 litoshi/vB
Inputs
Estimated size
Fee in litoshi
Fee in LTC
1
141 vB
282
0.00000282
2
209 vB
418
0.00000418
5
413 vB
826
0.00000826
10
753 vB
1506
0.00001506
20
1433 vB
2866
0.00002866
Original approximate size model; two P2WPKH outputs, ordinary signatures, no MWEB. Open full-size SVG. On a narrow screen, scroll the figure horizontally.
Every row uses two outputs and a hypothetical 2 /vB. A one-input transfer can therefore be cheaper than a ten-input transfer even when both send exactly the same LTC amount. The $ value of a payment does not directly determine its transaction size.
The two-input model gives 209 vB. At 2 litoshi/vB, that is 418 litoshi, matching the illustrative fee in the earlier diagram. The diagram's accounting identity is exact; the size assumption is an estimate. Keep those two claims separate.
Use the live fee page and the wallet's own transaction preview for current context. A relay-policy minimum is not a guaranteed next- price, and an exchange's fixed withdrawal charge is not necessarily the network fee of the transaction containing your withdrawal.
4. What coin control changes
Coin control lets you inspect and influence which spendable outputs fund a payment. It can be useful when you want to keep labeled groups separate, avoid a particular output, or understand why a transaction contains so many inputs. It does not modify consensus rules, make spent outputs usable again or conceal a transparent transaction.
Automatic selection is a reasonable starting point for many users. Manual selection adds decisions: the chosen outputs must cover the payment and fee, may create change, and may reveal relationships between previously separate receipts. Selecting the smallest number of inputs is only one objective; it is not a complete privacy policy.
Inspecting coin control in Litecoin Core
Use an up-to-date, authenticated Litecoin Core installation and the intended wallet. Confirm that your backup and recovery procedure are appropriate before making a real payment.
In the Options/Preferences dialog, open the Wallet tab and enable coin control features. This wording is present in the v0.21.5.8 UI definition.
Open the Send view and choose Inputs.... Review the available outputs and your labels.
Select only the outputs you intend to use. Inspect the quantity, total input value, estimated size, fee and change.
Review the recipient, amount and change behavior before authorizing. Recheck the final signed transaction if the wallet updates the estimate.
These steps are checked against the Options UI and Send UI, rather than presented as screenshots from every operating system.
Core's coin-control dialog also offers Lock unspent and Unlock unspent. These are wallet-selection controls, not an on-chain freeze. They do not stop another signer with the relevant keys from spending. Check whether your wallet preserves such selections or locks across restarts before relying on them. Source: coin-control dialog implementation.
5. Consolidation: compare two complete paths
Consolidation means spending several outputs into a smaller number of outputs you control. It costs a fee now. It may reduce a later payment's input count, but only if those outputs would otherwise have been needed for that later payment.
Consider ten P2WPKH inputs which you will later spend together. Keep the same approximate size model and compare two paths:
Consolidation comparison: 1 litoshi/vB now, 2 litoshi/vB later
Path
Size assumptions
Total modeled fee
Wait and spend ten inputs later
One transaction: 753 vB × 2
1,506 litoshi
Consolidate now, then spend later
722 vB × 1, plus 141 vB × 2
1,004 litoshi
Difference under these assumptions
1,506 − 1,004
502 litoshi (0.00000502 LTC)
The hypothetical saving is 502 litoshi. It depends on both fee rates and the assumed future spend. Algebraically, consolidation saves fees in this model only when:
722 × current fee rate + 141 × future fee rate
< 753 × future fee rate
future fee rate > (722 ÷ 612) × current fee rate
> about 1.180 × current fee rate
This is not a recommendation to consolidate whenever that ratio appears favorable. Future fee rates are unknown, outputs may be spent separately, script types may differ, and there is an immediate privacy cost if unrelated receipts are combined. Very small nominal savings may not justify an extra operational step.
6. Coin selection is also a privacy decision
Transparent transactions expose the inputs spent together. Analysts can treat common-input spending as a clue that outputs share control, but that is a heuristic, not proof of one person's identity. Collaborative transactions and custodial systems complicate the inference.
Imagine one receipt from a publicly identified business and another from an unrelated personal activity. Combining them may disclose a connection that keeping them separate would not have revealed through that particular transaction. Sending the resulting change to a fresh address does not erase the already published input relationship. The general risks of address reuse and public transaction linkage are explained in Bitcoin.org's privacy guidance; here the discussion is limited to the analogous transparent Litecoin transaction model.
Questions to ask before selecting inputs
Situation
Potential benefit
Tradeoff to examine
Many small receipts
Fewer future inputs after consolidation
An extra fee now; assumptions about the future spend
Receipts from different activities
Keeping groups separate can avoid one new public link
A suitable subset must still cover amount plus fee
Unknown small incoming payment
Excluding it can preserve separation
Wallet locks are local controls, not consensus rules
A very large payment
Combining enough value enables payment
Input count, change, and public linkage may grow
Automatic selection looks unexpected
Inspection can explain the wallet’s choice
Manual changes can make size or privacy worse
Maintain useful local labels for where receipts came from, and avoid posting wallet screenshots that reveal balances or addresses unnecessarily. Labels are your records, not a cryptographic privacy feature. Coin control also does not hide network-level information; see the separate Tor guide for that layer.
7. Small outputs, dust and suspicious receipts
“Dust” is not one universal LTC amount. Relay policy considers the output's script and an assumed future spending cost. Litecoin Core's dust calculation depends on the configured fee-rate input and distinguishes output types. Do not copy a Bitcoin dust number into a Litecoin wallet checklist without checking the relevant policy. Source: Litecoin Core dust-policy calculation.
A small output can also be uneconomic to spend at a particular market fee rate even when it is accepted by the network's policy. These are related but different tests: policy acceptability does not guarantee economic usefulness.
Receiving an unsolicited tiny payment does not, by itself, disclose your private key. The concern can be later linkage or a scam designed to make you interact with a fake service. Do not follow instructions embedded in unsolicited transaction messages, and do not send a “verification payment” to unlock the receipt. If your wallet supports it, leaving an identified suspicious output out of automatic spending can help preserve separation while you investigate. See our existing dusting and address-poisoning guide.
8. What changes with MWEB?
MWEB is not simply a transparent transaction with its amounts hidden in the same public fields. Litecoin Core distinguishes ordinary outpoints from MWEB output identifiers and has separate MWEB structures. The public input/output amounts and P2WPKH size formula in this guide must not be applied to MWEB transfers. Source: Core's canonical/MWEB input and output types.
Use the wallet's specific MWEB workflow and fee quote, check compatibility at both ends, and consult the MWEB learning path. Optional amount confidentiality does not make every deposit route compatible or erase all operational privacy risks.
9. A checklist before authorizing a payment
Purpose: Are you paying someone, moving funds between your wallets, or consolidating?
Inputs: Do you recognize the selected outputs and accept the relationships their joint spending reveals?
Coverage: Do inputs cover the intended recipient amount and fee?
Change: Is any remainder going to a wallet-controlled destination you intend?
Size and fee: Are you reading litoshi/vB, total litoshi and total LTC correctly?
Authorization: Does the final wallet or signer display match the payment you planned?
Verification: After broadcasting, check the transaction record and confirmations rather than relying on a copied “sent” message.
Yes. Separate payments can create separate outputs with spending conditions associated with the same address. Address count is not input count.
Is change an extra charge?
No. Change is value returned to an output you control. The fee is the input total minus the output total for the ordinary transparent transaction discussed here.
Should I consolidate all my LTC?
There is no universal rule. Model the additional transaction, possible later savings and privacy consequences. The numerical example assumes a particular future spend and does not predict fee rates.
Reproducibility and sources
Download the input-count and fee-model CSV. The SVG figures use these stated assumptions and contain no live blockchain claims. The technical references are the pinned Litecoin Core v0.21.5.8 source files linked above, the BIP 141 size definition and the developer documentation for the shared transparent transaction model. No mainnet transaction was sent to produce the examples, and the article does not claim a hands-on test of every wallet's UI.
Litecoin (LTC)
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief A fee per unit of transaction size, rather than the total charge, with MWEB using additional accounting.
A fee per unit of transaction size, rather than the total charge. For ordinary transparent Litecoin, wallets commonly quote litoshis per virtual byte. The estimated total depends on both that rate and the transaction's virtual size; MWEB adds different accounting.
For example An illustrative 200-vB transaction at 2 litoshis/vB costs 400 litoshis, while a 400-vB transaction at that rate costs 800.
Common mistake Reading 2 litoshis/vB as a 2-litoshi total, or assuming a recommended rate guarantees a confirmation time.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
In brief A linked record of transaction blocks that Litecoin nodes validate, choosing a valid chain by accumulated mining work.
A ledger of cryptographically linked blocks. Litecoin full nodes validate proposed blocks against consensus rules and select among valid chains by accumulated proof of work. Recent blocks can be reorganized, so confirmation depth matters.
For example A block explorer reads the chain so you can inspect where a transparent transaction was included.
Common mistake Assuming an explorer listing proves the sender's identity or that a recent block can never be replaced.
In brief Searching for valid proof of work and proposing Litecoin blocks that other nodes independently check.
Searching for proof of work and assembling candidate blocks that follow a network's rules. Validating nodes independently check proposed blocks. An accepted Litecoin block can pay its miner the permitted subsidy and transaction fees; a pool participant is paid under the pool's scheme.
For example An ASIC connected to a pool contributes proof-of-work attempts; the pool pays according to its published scheme.
Common mistake Comparing coin revenue without subtracting electricity, pool charges, downtime and equipment costs.
In brief An unspent output from an earlier transaction, used whole when selected for an ordinary transparent payment.
An unspent transaction output: a recorded amount from an earlier transaction that has not been spent. A transparent Litecoin wallet can select eligible UTXOs as inputs for a new payment. Each selected output is spent in full; value left after the payment and fee can return as change.
For example Fictional receipts of 0.4 LTC and 0.6 LTC can be two UTXOs even when a wallet shows a single 1 LTC balance.
Common mistake Assuming the displayed wallet balance is one indivisible account entry, or that spending an input sends all of it to the recipient.
In brief Wallet controls for choosing available transaction outputs to spend, affecting fees, change and links between payments.
Wallet features that let you inspect and choose which available outputs a payment spends. The selected inputs affect transaction size, change and which previous receipts become linked. Manual selection does not bypass signing, maturity or wallet-policy requirements.
For example Choose one suitable UTXO instead of combining several unrelated receipts, then review the resulting fee and change.
Common mistake Assuming manual selection guarantees lower fees or privacy, or that a visible but unavailable output can fund a payment.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief A transaction ID plus an output number, identifying one specific output of a transparent transaction.
The pair that identifies one output of an ordinary transparent transaction: its TXID and zero-based output index, often called vout. One transaction can create several outputs, so a transaction ID alone does not identify which one you mean.
For example TXID plus vout 0 and the same TXID plus vout 1 identify different outputs, even if both use the same receiving address.
Common mistake Assuming the recipient is always output zero or treating an address balance as the state of one specific output.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief A tool showing its indexed view of public blockchain data, which cannot reveal a service's internal account status.
A website or app that indexes blockchain data so you can inspect blocks, transactions and outputs. It reports its own data view. Looking up a public transaction needs no private key, and an explorer cannot see a service's internal account-crediting decisions.
For example Look up a transparent Litecoin TXID to check the destination output, amount and reported confirmations.
Common mistake Entering recovery words to track a public transaction, or treating one explorer's missing result as proof that no payment exists.
In brief A wallet view that can show addresses and activity from public information but cannot sign a payment on its own.
A wallet view built from public information that can recognize addresses and transactions without holding their private signing keys. It can show a balance or help prepare a payment, but spending needs the appropriate signer or cosigners through a supported workflow.
For example Importing an address or xpub can reproduce a receiving view while leaving that wallet unable to sign on its own.
Common mistake Treating matching addresses or a displayed balance as proof that recovery also restored spending authority.
In brief Secret data a wallet uses to sign spending; one key may cover only part of a wallet and must never be shared.
Secret data used to authorize spending under the conditions attached to coins. In a simple single-key wallet, anyone with that key can spend the coins it controls. A wallet may manage many keys; never share them.
For example A wallet signs a spend using a private key; the recipient only needs your payment, not that secret key.
Common mistake Sharing a key with support or assuming one exported key necessarily backs up every address in a wallet.
Compare: Seed phrase vs private key
Seed Phrase
Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
Private Key
A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
In brief A transaction gains confirmations as blocks build on its inclusion, but those confirmations can fall if chain history changes.
A transaction receives its first confirmation when included in a block in the accepted chain. Each block then built on top adds another. A chain reorganization can reduce or remove the count. The recipient decides how many confirmations it requires. Litecoin targets an average 2.5-minute block interval; individual blocks can arrive sooner or much later.
For example A transaction in the latest accepted block has one confirmation; the next block raises that count to two.
Common mistake Confusing a wallet's sent message, a TXID or mempool visibility with the first confirmation.
In brief A wallet-controlled destination for leftover LTC after spending an input on a payment and its fee.
Spending a transparent transaction output uses its whole value. After paying the recipient and fee, a wallet can send the leftover LTC to an address it controls. That destination is a change address. Wallets usually choose it automatically.
For example A fictional 1 LTC input paying 0.3 LTC with a 0.00001 LTC fee can return 0.69999 LTC to a wallet-controlled change output.
Common mistake Assuming an unfamiliar second output is a second payment to the recipient; first check which outputs your wallet owns.
In brief For ordinary transparent Litecoin transactions, the fee is total input value minus total output value, separate from a service withdrawal charge.
For an ordinary transparent Litecoin transaction, the network fee is the total input value minus all output values, including change. Wallets estimate it using transaction size and a fee rate, so sending more LTC does not automatically mean a higher fee. A service's withdrawal charge is a separate quote and may already cover network costs.
For example Fictional inputs total 1 LTC, while recipient and change outputs total 0.99999 LTC: the network fee is 0.00001 LTC.
Common mistake Confusing fee rate with total fee, leaving change out of output totals, or equating a service's withdrawal charge with the full network fee.
Compare: Network fee vs withdrawal fee
Transaction Fee
An ordinary transparent transaction's network fee is its total input value minus its total output value; transaction size and fee rate help determine the estimate.
Withdrawal Fee
A service sets its withdrawal charge under its own rules, and that charge can differ from the network fee on the transaction it broadcasts.
One example If a fictional service deducts a 0.001 LTC charge from a 1 LTC withdrawal, the recipient receives 0.999 LTC; these figures do not reveal the transaction's network fee.
Remember: Check the final account debit, recipient amount and minimum separately; add a network-fee estimate only if it is an additional charge, so the same cost is not counted twice.
In brief A service for trading currencies or assets, whose custodial account balance does not give you control of its private keys.
A platform or service for buying and selling cryptocurrencies against fiat currencies or other assets. Trading methods, custody, supported pairs and withdrawal rules vary by service. A balance on a custodial exchange is an account claim; it does not mean you control the wallet's private keys.
For example After buying LTC on a custodial exchange, you request a withdrawal if you want it sent to your own wallet.
Common mistake Assuming an account balance means you possess the private keys, or overlooking the selected withdrawal network.
In brief A device designed to keep signing keys isolated while approving supported transactions, still requiring safe setup and backups.
A dedicated device designed to isolate signing keys and approve transactions through its supported interface. It still depends on correct setup, backups, supported software and careful review of the recipient and amount. Coins remain recorded on the blockchain.
For example A connected app prepares a payment while the hardware device displays details for you to verify before authorizing a signature.
Common mistake Assuming owning the device makes an exposed recovery phrase safe or removes the need to check what you authorize.
In brief A transaction format and validation change that separates witness data and changes how block capacity is counted.
Segregated Witness: a change to transaction serialization and validation that separates witness data, fixes certain transaction-malleability issues and changes capacity accounting. Litecoin activated it in May 2017.
For example An ltc1q receiving address uses a SegWit format; the sender still needs to check that its service accepts that address.
Common mistake Assuming every wallet supports every address format, or that SegWit guarantees a fixed confirmation time.
In brief A fee-sizing unit for ordinary transparent transactions, usually weight divided by four and rounded up.
A size unit used when quoting fees for ordinary transparent transactions. The usual calculation divides transaction weight by four and rounds up; node policy can also account for signature-operation cost. It can differ from the raw serialized byte count. Use the size unit expected by the quoted fee rate.
For example A transparent transaction with weight 565 has a virtual size of 142 vB, because the division rounds up.
Common mistake Multiplying a litoshi-per-vB rate by an unrelated raw-byte count or assuming the same formula covers every MWEB component.
In brief A single-key SegWit output type; Litecoin's ltc1q prefix alone does not distinguish it from P2WSH.
A SegWit version-0 output type that commits to a public-key hash. Spending it places the signature and public key in witness data. Its native Litecoin mainnet address uses ltc1q, but that prefix also covers P2WSH, so the prefix alone is insufficient for a precise fee model.
For example The fee estimator's native SegWit input option models P2WPKH. Check the wallet's actual script type before selecting it.
Common mistake Assuming every ltc1q output is the single-key P2WPKH type or confusing its witness bytes with full-price base bytes.
In brief A spending rule requiring a set number of key signatures, with the wallet policy also needed for recovery.
A spending policy requiring signatures from a stated number of keys, such as two of three. Recovery also needs the correct script or wallet policy and enough signing keys; one cosigner's seed is not necessarily sufficient.
For example In a 2-of-3 policy, any two of the three authorized keys can satisfy the signing threshold.
Common mistake Keeping enough seeds but losing the script or key-order information needed to reconstruct the wallet.
In brief An informal name for 0.00000001 LTC, the smallest Litecoin unit, with 100,000,000 in one LTC.
An informal name for the smallest Litecoin unit: 0.00000001 LTC. One LTC contains 100,000,000 litoshis. Some software uses the inherited label satoshi, so always check which coin and unit a screen means.
For example 10,000 litoshis equal 0.0001 LTC; 1 litoshi equals 0.00000001 LTC.
Common mistake Confusing a fee quoted per virtual byte with that many litoshis for the whole transaction.
In brief A group of transactions linked to the previous block under the network's rules.
A batch of transactions accepted under the network rules and linked to the previous block. Litecoin targets one new block every 2.5 minutes on average; a particular block may arrive sooner or much later.
For example Your payment may wait unconfirmed and then receive its first confirmation when a miner includes it in an accepted block.
Common mistake Treating the 2.5-minute target as a countdown or a maximum wait for your payment.
Content review recorded: 2026-09-18. The review record does not identify a separate independent reviewer. An edited date above records an edit, not a new fact-check. AI-assisted editing or new artwork alone does not complete a source review.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
