What makes it Ember, what makes it Glow
Every share you submit is an ember— and EMBER Glow does two things with it that ordinary pools don’t.
Ember keeps your work at full value · Glow pays it out, block by block, into your own wallet.
A steady glow, not a lucky spark
Mine alone and the same work pays you nothing for a long stretch, then everything at once. EMBER Glow pays you out of every block the pool finds while your work is in the window. Over a long enough run both track the work you did — one just arrives in a rhythm you can plan around, and takes a small fee for doing so.
What’s steady is the cadence, not the amount. Each payment is your share of the work sitting in the window, so it moves when your own hashrate moves or when other miners come and go. Hold a steady rig and your slices hold steady; switch a rental on and your next slices grow to match. What never varies is that the work is counted at full value while it is in the window.
One shift of work. Eight blocks’ worth of paydays.
Your work doesn’t pay once and vanish. Hash today and it earns a slice of every block the pool finds until eight blocks’ worth of pool work have gone by — at full value every time, not a little less with each one. Then it retires. How many payments that works out to is luck: eight is the average, and a lucky stretch pays you from more while a quiet one pays you from fewer. What is fixed is the work you are paid across, not the number of times you are paid.
Hash once today → an equal cut of each block the pool finds, until eight blocks’ worth of pool work have passed. Then that share is done — it does not trail off, and it is not cut short by a block-find. The cuts are equal; how many of them there are is the pool’s luck.
Full value, then it retires — no long tail
du(s) is what one share is worth: the work it proved, divided by the network difficulty it was proved against. Inside the window every share is worth exactly that — no decay curve, no freshness bonus, and no advantage to reconnecting at the right moment. One you sent at the start of the window is worth what one you sent a second ago is worth. Dividing by network difficulty is also what makes the number unitless, which is why one kernel pays a 2-decimal chain and a 12-decimal chain with no per-coin arithmetic.
1[ U(s) < 8 ] is the window, and it is where it stops. U(s)is how much work the pool has done since your share landed, counted in blocks’ worth rather than on a clock. While that is under eight, your share counts in full; at eight it is finished and pays nothing further. We say that plainly because it is the honest trade: a flat window pays the most predictable amount per unit of work, and the price of that is a defined ending rather than a tail fading toward zero.
Two places the notation is tidier than the code. Written as an indicator the edge looks like a hard in-or-out, but the share that straddles it is actually pro-rated — paid for exactly the fraction of it that fits inside the window, not rounded either way.
And U has no clock in it, but the query that reads your shares does have a floor: it looks back a bounded distance rather than forever — a yearon every pool running this model. On a pool moving at DigiByte’s pace it never binds — eight blocks of pool work arrive in about a day, long before a year does. On a pool quiet enough that a year passes first, it binds and stays bound, and from then on a year of work rather than eight blocks of it is what your share is measured across. When it binds, the engine logs a warning and pays on the shortened window anyway rather than failing the block — so on a pool slow enough to reach it, your oldest work would quietly stop earning while everything else carried on looking normal. That is the one way elapsed time can touch your weight, and it is why it is written down here rather than left out.
From your rig to your wallet — in the block itself
When this pool finds a block, the coinbase transaction is built with one output per miner in the window, paid to the address that miner authorised with. That transaction is the block. There is no second step, no payout run, no sweep, and no moment where FenixPool is holding your coins and could choose not to send them.
Two things follow, and one of them is not in your favour. Payouts are final — once a block is accepted its coinbase cannot be revised, so nobody can claw your coins back and nobody can correct a mistake after the fact either. And a coinbase output has to mature. Your share is fixed in the block the instant it is accepted, but like every coinbase on every chain it is not spendable until it has aged — 100 further blocks on Bitcoin, Bitcoin Cash, DigiByte and eCash, and 240 on Dogecoin. If that block is later orphaned off the chain the payout goes with it and pays nothing, while the work behind it stays in your window and earns from the next block instead.
Your pay, step by step
- You point a miner at a pool port and authorise with your own wallet address as the username. No account, no password that matters, no sign-up.
- Each accepted share is recorded with the difficulty it was assigned and the network difficulty it was mined against. Your weight is the ratio of the two.
- When the pool finds a block, it takes every share inside the window, sums the weights, and gives you your fraction of the reward, down to the satoshi. Division leaves a remainder of a few satoshi. Almost all of it is spread back across miners rather than kept; only the last sliver of rounding — at most one satoshi per payee — settles into the fee output.
- The pool fee comes off the top of the block before that split, and it runs between 0% and 1% depending on the coin. The live rate for each pool is on its card below; that card, not this sentence, is the authority.
- Your slice is written into the block’s coinbase as an output to your address. You are paid the moment the block is accepted by the network.
- That share keeps paying from the pool’s next blocks until eight blocks of work have passed on top of it.
Where this sits next to PPLNS, FPPS and solo
| model | who holds your coins | minimum payout | pool fee | what you're exposed to |
|---|---|---|---|---|
| EMBER Glow (this) | nobody — paid in the block | none, only chain dust | 0–1%, by coin | pool luck |
| PPLNS (typical) | usually the pool, until you withdraw | usually a threshold | set by that pool | pool luck + custody |
| FPPS / PPS | the pool, until you withdraw | usually a threshold | prices the variance it absorbs | custody + operator solvency |
| Solo | nobody — paid in the block | none, only chain dust | set by that pool | your own luck, entirely |
Two honest notes on the table. Custody is not part of PPLNS— PPLNS is a rule for weighting shares and says nothing about who holds the coins. Most implementations are custodial, which is why the row reads that way, but FenixPool’s own share-proportional pools pay into the block exactly like this one does. And FPPS really does remove your variance— it pays a fixed amount per share whether the pool finds a block or not, absorbing the risk and charging for it. EMBER Glow does not do that. You are exposed to the pool’s luck. What you get instead is that nobody holds your coins and there is no threshold to reach.
From a whole farm down to a single Bitaxe
There is no minimum hashrate and no threshold set by this pool. A Bitaxe in the window is an output in the coinbase exactly like a farm is, scaled by the work it did. The only floor anywhere is the chain’s own dust limit, and by default a slice landing under it is spread across the miners who clear it rather than kept — a per-pool setting, not a rule of the model. Two honest caveats: if nobody in the window clears the floor there is no one to spread it among and the whole miner pool goes to the fee output instead, and no slice has yet landed under the dust floor on a live block, so that path has been exercised in tests rather than in production.
The bars are on a log scale, so a device is not paid anything like its bar suggests relative to the one above it — a farm here is roughly three thousand times the Bitaxe, and would be paid roughly three thousand times as much for the same window. The bars show that every rung is on the same ladder, not how much each one earns.
A big miner can't crowd you out
Your slice is your share of the work in the window. If a large miner joins, the pool finds blocks more often and the window fills faster — you get a smaller fraction of more frequent blocks. Over any stretch of time your pay tracks the work you did, not who else showed up.
Splitting one miner across many addresses gains nothing: weight is linear in work, so five addresses with a fifth of the work each are paid the same as one address with all of it, to within rounding. That is not a policy against splitting, it is arithmetic: the weight function is linear in work, so summing five weights or weighting one sum gives the same number. The only difference is the integer rounding on each output, worth a few satoshi either way.
EMBER Glow pools
5 pools run on this model today — point a miner and watch it work in real time.
Frequently asked
Tap a question to open its answer.
Do I need an account?
When do I get paid?
Why was my payout smaller than last block?
Is there a minimum payout?
What happens when I stop mining?
Can the pool run off with my coins?
Does finding the block earn me more?
What's the fee?
Can I check the maths myself?
Paid from the block. Not from a promise.
Point a miner, use your own address, and check the coinbase yourself.




