Welcome to the Olenza channel.
Olenza is a small project currently: full nodes for nine blockchains, and tools on top of them.
• Explorer: blocks, transactions and addresses for Bitcoin, Ethereum, Litecoin, Dogecoin, Bitcoin Cash, eCash, Zcash, Decred and Monero, with charts and stats.
• Node API: JSON-RPC to the same nodes with one API key. Free plan: 10,000 calls a day.
• Explorer API: the explorer's data over REST.
No trackers on the sites, and you can pay for plans in BTC, LTC, ETH, USDT or USDC.
Here I'll post short, useful explainers about how these chains work and how to read them on the explorer, plus updates and fixes. It's early and it's one person, so feedback and bug reports are very welcome.
olenza.io
#Olenza #Bitcoin #Blockchain
Olenza is a small project currently: full nodes for nine blockchains, and tools on top of them.
• Explorer: blocks, transactions and addresses for Bitcoin, Ethereum, Litecoin, Dogecoin, Bitcoin Cash, eCash, Zcash, Decred and Monero, with charts and stats.
• Node API: JSON-RPC to the same nodes with one API key. Free plan: 10,000 calls a day.
• Explorer API: the explorer's data over REST.
No trackers on the sites, and you can pay for plans in BTC, LTC, ETH, USDT or USDC.
Here I'll post short, useful explainers about how these chains work and how to read them on the explorer, plus updates and fixes. It's early and it's one person, so feedback and bug reports are very welcome.
olenza.io
#Olenza #Bitcoin #Blockchain
How to read a Bitcoin transaction
Bitcoin has no account balances. A transaction spends earlier outputs (its inputs) and creates new outputs. Each input points back to the output it spends: a txid and an index, like df61ae3700…:0.
The one in the picture, from block 970,360:
• 3 inputs, 0.0487939 BTC in total
• 2 outputs, 0.0487765 BTC
• the difference, 0.0000174 BTC, is the fee. No output says "fee"; it is whatever the outputs don't claim.
Two outputs often means a payment plus change back to the sender, but nothing on chain says which is which. Any label saying "change" is a guess.
Confirmations count the blocks from the one holding the transaction up to the tip, that block included. Each new block makes reversing it harder, which is why services wait for 1 to 6 depending on the amount.
Paste any txid, address or block height into the search box:
explorer.olenza.io/btc
#Bitcoin #Explorer #Olenza
Bitcoin has no account balances. A transaction spends earlier outputs (its inputs) and creates new outputs. Each input points back to the output it spends: a txid and an index, like df61ae3700…:0.
The one in the picture, from block 970,360:
• 3 inputs, 0.0487939 BTC in total
• 2 outputs, 0.0487765 BTC
• the difference, 0.0000174 BTC, is the fee. No output says "fee"; it is whatever the outputs don't claim.
Two outputs often means a payment plus change back to the sender, but nothing on chain says which is which. Any label saying "change" is a guess.
Confirmations count the blocks from the one holding the transaction up to the tip, that block included. Each new block makes reversing it harder, which is why services wait for 1 to 6 depending on the amount.
Paste any txid, address or block height into the search box:
explorer.olenza.io/btc
#Bitcoin #Explorer #Olenza
👍1
Why Bitcoin fees go up and down
A block holds about 1,000,000 virtual bytes (4 million weight units). Transactions waiting for a block sit in each node's mempool, and miners generally take the ones paying the most per vbyte first.
So you pay for space, not for the amount. The transaction from our last post moved 0.0488 BTC, took 276 vB and paid 1,740 sat: 6.30 sat/vB. The same inputs and outputs carrying 100 BTC would cost exactly the same.
• More inputs make a bigger transaction and a bigger fee. SegWit helps because witness data counts at a quarter.
• When more is waiting than the next blocks can hold, the rate needed to get in rises. When the queue is short, almost anything gets in.
• Bitcoin Core 29.1 lowered its default minimum relay rate from 1 to 0.1 sat/vB, so rates under 1 now appear.
The Bitcoin page shows our node's estimate for confirmation within 1, 6 and 144 blocks (fast, normal, slow).
explorer.olenza.io/btc
#Bitcoin #Fees #Olenza
A block holds about 1,000,000 virtual bytes (4 million weight units). Transactions waiting for a block sit in each node's mempool, and miners generally take the ones paying the most per vbyte first.
So you pay for space, not for the amount. The transaction from our last post moved 0.0488 BTC, took 276 vB and paid 1,740 sat: 6.30 sat/vB. The same inputs and outputs carrying 100 BTC would cost exactly the same.
• More inputs make a bigger transaction and a bigger fee. SegWit helps because witness data counts at a quarter.
• When more is waiting than the next blocks can hold, the rate needed to get in rises. When the queue is short, almost anything gets in.
• Bitcoin Core 29.1 lowered its default minimum relay rate from 1 to 0.1 sat/vB, so rates under 1 now appear.
The Bitcoin page shows our node's estimate for confirmation within 1, 6 and 144 blocks (fast, normal, slow).
explorer.olenza.io/btc
#Bitcoin #Fees #Olenza
How an explorer turns Ethereum hex into transfer(_to, _value)
A contract call is just bytes in the transaction's input field. The first 4 bytes are the function selector: the start of the keccak-256 hash of the function's signature. keccak256("transfer(address,uint256)") begins with a9059cbb, so input starting 0xa9059cbb is almost always a token transfer. The arguments follow, 32 bytes each (ABI spec). That's why this USDT transfer has 138 characters of input: 0x + 8 + 64 + 64.
With the contract's verified ABI (from Sourcify) the explorer can name the arguments: _to, and _value = 33,795,506. USDT has 6 decimals, so that is 33.795506 USDT.
The token movement itself is read from the logs. Contracts emit events; Transfer(address,address,uint256) has topic 0xddf252ad…, and that is what the "Token transfers" table is built from.
4 bytes can collide, so "verified ABI" on the page means the contract's own ABI was used, not a guess from the selector.
explorer.olenza.io/eth
#Ethereum #ERC20 #Olenza
A contract call is just bytes in the transaction's input field. The first 4 bytes are the function selector: the start of the keccak-256 hash of the function's signature. keccak256("transfer(address,uint256)") begins with a9059cbb, so input starting 0xa9059cbb is almost always a token transfer. The arguments follow, 32 bytes each (ABI spec). That's why this USDT transfer has 138 characters of input: 0x + 8 + 64 + 64.
With the contract's verified ABI (from Sourcify) the explorer can name the arguments: _to, and _value = 33,795,506. USDT has 6 decimals, so that is 33.795506 USDT.
The token movement itself is read from the logs. Contracts emit events; Transfer(address,address,uint256) has topic 0xddf252ad…, and that is what the "Token transfers" table is built from.
4 bytes can collide, so "verified ABI" on the page means the contract's own ABI was used, not a guess from the selector.
explorer.olenza.io/eth
#Ethereum #ERC20 #Olenza
Reading a smart contract without connecting a wallet
Functions marked view or pure don't change anything. A node can run them with eth_call: it executes the code against a chosen block and returns the result. No transaction, no signature, no fee, nothing broadcast.
The Read tab on a contract page does exactly this on our own archive node, using the verified ABI from Sourcify. For USDT you see name, symbol, decimals (6), totalSupply, owner and paused, all read at the block number shown on the page. Functions with arguments, such as balanceOf(address), take an input and answer the same way.
Why this is useful: you can check what a contract reports about itself (who owns it, whether it can be paused, its supply) before you approve or send anything. Reading public data never needs your keys.
explorer.olenza.io/eth
#Ethereum #SmartContracts #Olenza
Functions marked view or pure don't change anything. A node can run them with eth_call: it executes the code against a chosen block and returns the result. No transaction, no signature, no fee, nothing broadcast.
The Read tab on a contract page does exactly this on our own archive node, using the verified ABI from Sourcify. For USDT you see name, symbol, decimals (6), totalSupply, owner and paused, all read at the block number shown on the page. Functions with arguments, such as balanceOf(address), take an input and answer the same way.
Why this is useful: you can check what a contract reports about itself (who owns it, whether it can be paused, its supply) before you approve or send anything. Reading public data never needs your keys.
explorer.olenza.io/eth
#Ethereum #SmartContracts #Olenza
Decred: tickets, voting and the treasury
Decred blocks are mined with proof of work, but holders of DCR have the final say. Anyone can lock DCR to buy a ticket. Each block draws 5 live tickets at random; at least 3 votes must be included, and they also approve or reject the regular transactions of the previous block.
The block reward is split 1% to miners, 89% to voting tickets, 10% to the treasury (DCP-0012). The ticket price is recalculated every 144 blocks (about 12 hours) to keep the pool near 40,960 tickets. A missed or expired ticket returns its price, without the reward.
Tickets also vote on rule changes (consensus agendas), and every treasury spend needs a yes from ticket votes on chain.
On 7 Oct, block 1,121,616:
• 41,012 tickets in the pool, 11,345,165 DCR locked
• ticket price 276.62 DCR
• treasury 882,060 DCR
• of 5,666,895 tickets ever bought: 97.5% voted, 1.1% missed, 0.7% expired
explorer.olenza.io/dcr/stats
#Decred #ProofOfStake #Olenza
Decred blocks are mined with proof of work, but holders of DCR have the final say. Anyone can lock DCR to buy a ticket. Each block draws 5 live tickets at random; at least 3 votes must be included, and they also approve or reject the regular transactions of the previous block.
The block reward is split 1% to miners, 89% to voting tickets, 10% to the treasury (DCP-0012). The ticket price is recalculated every 144 blocks (about 12 hours) to keep the pool near 40,960 tickets. A missed or expired ticket returns its price, without the reward.
Tickets also vote on rule changes (consensus agendas), and every treasury spend needs a yes from ticket votes on chain.
On 7 Oct, block 1,121,616:
• 41,012 tickets in the pool, 11,345,165 DCR locked
• ticket price 276.62 DCR
• treasury 882,060 DCR
• of 5,666,895 tickets ever bought: 97.5% voted, 1.1% missed, 0.7% expired
explorer.olenza.io/dcr/stats
#Decred #ProofOfStake #Olenza
Litecoin MWEB: what peg-in and peg-out mean
Since May 2022 Litecoin has an optional privacy layer, MimbleWimble Extension Blocks (MWEB). Coins move in and out of it in plain sight:
• Peg-in: a normal transaction sends LTC to a special MWEB output (witness version 9). The amount is public.
• Inside MWEB, amounts are hidden behind commitments and no addresses appear on chain.
• Peg-out: coins come back to a normal Litecoin address, and that amount is public again.
On the main chain, every coin inside MWEB sits in one output that each block re-creates (the HogEx transaction). So an explorer can show how much is inside, 453,223 LTC at block 3,191,200 on 7 Oct, and how much went in and out each day. It cannot show who holds it or who paid whom.
One caution: pegging in 12.3456 LTC and pegging the same 12.3456 out an hour later links the two by amount. The privacy depends on how it is used.
explorer.olenza.io/ltc/stats
#Litecoin #MWEB #Privacy #Olenza
Since May 2022 Litecoin has an optional privacy layer, MimbleWimble Extension Blocks (MWEB). Coins move in and out of it in plain sight:
• Peg-in: a normal transaction sends LTC to a special MWEB output (witness version 9). The amount is public.
• Inside MWEB, amounts are hidden behind commitments and no addresses appear on chain.
• Peg-out: coins come back to a normal Litecoin address, and that amount is public again.
On the main chain, every coin inside MWEB sits in one output that each block re-creates (the HogEx transaction). So an explorer can show how much is inside, 453,223 LTC at block 3,191,200 on 7 Oct, and how much went in and out each day. It cannot show who holds it or who paid whom.
One caution: pegging in 12.3456 LTC and pegging the same 12.3456 out an hour later links the two by amount. The privacy depends on how it is used.
explorer.olenza.io/ltc/stats
#Litecoin #MWEB #Privacy #Olenza
Who finds Litecoin's blocks?
Last 30 days, up to block 3,191,200 (7 Oct):
• F2Pool 33.2%
• ViaBTC 21.9%
• AntPool 17.7%
• Kupool 6.7%
• unknown 17.5%
A pool is not one miner. It coordinates many machines, and their owners can point them elsewhere. But the pool operator decides which transactions go into its blocks and which tip to build on. This month two pools, F2Pool and ViaBTC, found about 55% of blocks. Anyone controlling more than half of the hash rate could in principle rewrite recent blocks or keep chosen transactions out. Nothing suggests that is happening; it is simply the number worth watching.
Litecoin and Dogecoin are merge-mined (both Scrypt), so much of the same hardware secures both chains.
How we count: a block is credited to a pool only when its coinbase tag or payout address matches mempool.space's public pool list. Anything else stays "unknown" rather than a guess.
explorer.olenza.io/ltc/stats
#Litecoin #Mining #Olenza
Last 30 days, up to block 3,191,200 (7 Oct):
• F2Pool 33.2%
• ViaBTC 21.9%
• AntPool 17.7%
• Kupool 6.7%
• unknown 17.5%
A pool is not one miner. It coordinates many machines, and their owners can point them elsewhere. But the pool operator decides which transactions go into its blocks and which tip to build on. This month two pools, F2Pool and ViaBTC, found about 55% of blocks. Anyone controlling more than half of the hash rate could in principle rewrite recent blocks or keep chosen transactions out. Nothing suggests that is happening; it is simply the number worth watching.
Litecoin and Dogecoin are merge-mined (both Scrypt), so much of the same hardware secures both chains.
How we count: a block is credited to a pool only when its coinbase tag or payout address matches mempool.space's public pool list. Anything else stays "unknown" rather than a guess.
explorer.olenza.io/ltc/stats
#Litecoin #Mining #Olenza
Zcash shielded pools, and why their totals are public
Zcash has transparent addresses, which work like Bitcoin's, and shielded ones, where sender, receiver and amount are encrypted and zero-knowledge proofs show the transaction is valid. Shielded value is kept in pools, one per protocol generation:
• Sprout (2016), closed to new deposits since Canopy (2020)
• Sapling (2018)
• Orchard (2022)
• Ironwood (NU6.3, July 2026), added after a soundness bug was found in Orchard. Orchard no longer takes new funds, and coins leave it through the "turnstile", which never lets out more ZEC than went in.
That turnstile is why pool totals are public: the chain tracks what enters and leaves each pool, so anyone can check that no ZEC was created inside one, without seeing a single shielded transaction.
On 7 Oct about 4.95 million ZEC was shielded: Ironwood 4.07M, Sapling 0.48M, Orchard 0.38M, Sprout 0.02M.
explorer.olenza.io/zec/charts
#Zcash #Privacy #Olenza
Zcash has transparent addresses, which work like Bitcoin's, and shielded ones, where sender, receiver and amount are encrypted and zero-knowledge proofs show the transaction is valid. Shielded value is kept in pools, one per protocol generation:
• Sprout (2016), closed to new deposits since Canopy (2020)
• Sapling (2018)
• Orchard (2022)
• Ironwood (NU6.3, July 2026), added after a soundness bug was found in Orchard. Orchard no longer takes new funds, and coins leave it through the "turnstile", which never lets out more ZEC than went in.
That turnstile is why pool totals are public: the chain tracks what enters and leaves each pool, so anyone can check that no ZEC was created inside one, without seeing a single shielded transaction.
On 7 Oct about 4.95 million ZEC was shielded: Ironwood 4.07M, Sapling 0.48M, Orchard 0.38M, Sprout 0.02M.
explorer.olenza.io/zec/charts
#Zcash #Privacy #Olenza
What a Monero explorer can and cannot show
Monero hides three things by default:
• Sender: each input is signed with a ring signature. The real output is hidden among 15 decoys (ring size 16), and a key image stops it being spent twice without revealing which one it is.
• Receiver: each output goes to a one-time stealth address. Your public address never appears on chain.
• Amount: RingCT hides it, with range proofs showing it is valid.
A transaction page shows the fee, size, key images, rings and one-time keys. No addresses, no amounts. Apart from fees, the block reward is the only public amount.
A recipient can check payments with their view key. Our checker takes it by POST and discards it once the result is computed. Share it carefully: it shows every payment to that wallet.
No trackers on our sites. Server logs are deleted after 14 days; explorer page logs include the URL you opened, API logs only the route, ids replaced. More: olenza.io/privacy
explorer.olenza.io/xmr
#Monero #Privacy #Olenza
Monero hides three things by default:
• Sender: each input is signed with a ring signature. The real output is hidden among 15 decoys (ring size 16), and a key image stops it being spent twice without revealing which one it is.
• Receiver: each output goes to a one-time stealth address. Your public address never appears on chain.
• Amount: RingCT hides it, with range proofs showing it is valid.
A transaction page shows the fee, size, key images, rings and one-time keys. No addresses, no amounts. Apart from fees, the block reward is the only public amount.
A recipient can check payments with their view key. Our checker takes it by POST and discards it once the result is computed. Share it carefully: it shows every payment to that wallet.
No trackers on our sites. Server logs are deleted after 14 days; explorer page logs include the URL you opened, API logs only the route, ids replaced. More: olenza.io/privacy
explorer.olenza.io/xmr
#Monero #Privacy #Olenza