Confirm before anything else

Registering an email sends only a confirmation message. Alerts stay off until you open the confirm link. You can register up to five addresses per signup.

What you can turn on

Preference	Default	When it sends
Maintenance / system	On	Operator notices about planned downtime or important pool changes
Blocks that pay my wallet	On	A confirmed pool block that includes a coinbase payout for your UA
Every pool block	Off	Every confirmed pool win, whether or not you were paid in that coinbase
Daily pool statistics	Off	A once-per-day digest of pool-wide activity for the previous US Central calendar day (CT)
Daily wallet statistics	On	Once-per-day digest for your UA: historical payout luck (30/60/90/120d), combined totals, and daily coinbase rewards in Central Time

What’s in a block email

Wallet alerts include when the block was found (Central Time), your payout, your share of the miner pool, TIDES expectation context, a compact 30-day payout-luck snapshot, lifetime paid / blocks paid / blocks found, and a short 24h pool-luck panel. Full historical luck tables live in the daily wallet digest. Pool-wide alerts include miner reward, paid-to-miners, fee/dust, the finder worker, found time (CST/CDT), and luck.

Manage or leave

Every alert footer has Choose which emails you get, Add or remove wallet email addresses, and Unsubscribe from all links (also standard unsubscribe headers). These links work directly from the email; you do not need to return to the main dashboard.

Once a wallet has a verified email, the Connect form cannot change membership. Open Add or remove wallet email addresses from a verified, still-subscribed Sluicey email. Existing verified active addresses receive the request; any one may approve or reject. An approved new address must still confirm its own inbox before alerts begin. Unsubscribe also revokes approval authority.

More help: frequently asked questions · contact us.

Pool pulse. Live TIDES window and estimated pool hashrate — not a wall of tables. Height, hashrate, workers active, shares, window multiplier, and blocks found at a glance.

Workers / miner login. Point software at address.rig (or the short worker login). Stats roll up to the Unified Address.

Workers active. Distinct worker names with an accepted share in the last 10 minutes (pool-wide and on the miner status tiles).

Worker status tiles. Click a tile to filter the workers table. Active = share in the last 10 minutes. Offline tiles split under/over 24 hours. Needs attention flags flapping reconnect churn.

Workers table. Roster looks back 30 days. Share counts are 24h. Hashrate columns are 1h / 3h / 24h. Export to Excel downloads the current filtered and sorted set (all matching rows, not just the page). The workers CSV column last_share_ct is US Central with a numeric offset (the previous column was the raw UTC instant).

Hashrate charts. Equihash Sol/s from accepted shares (scaled to powLimit). Avg ignores idle gaps. Axis and tooltip times are US Central (America/Chicago, CT). Block markers stack within a ~2 hour window (earliest at the bottom). On the miner chart, gold = other pool finds (same as the dashboard); a brighter gold mark means this address found that block.

Contributors. Ranked by work credited in the last 3 hours. Workers = distinct names with a share in the last 10 minutes (same window as Workers active above). Blocks = found by that address (not merely paid in the coinbase).

Recent blocks / coinbase payouts. Pool wins pay via ZIP-213 shielded multi-output coinbase with zero OVK (publicly auditable). Block hashes open on Zcashinfo. “Blocks won” for a worker are winning shares that worker submitted. Coinbase payout export downloads every paid row as a formatted Excel workbook (not just the current page).

Rules

1. Every accepted share is stored distinctly, in arrival order, weighted by its target difficulty.
2. When a block is found, the miner-available reward (subsidy + fees − funding streams) is split across a rolling window of about 8 × network difficulty in work.
3. Each miner receives a proportional cut of that window after the pool fee.
4. Rounding remainder and the pool fee go to the operator Unified Address in the same coinbase — non-custodial. See the live fee policy.
5. The window tip is fixed at job issue time, not submit time (anti-cheat).

Short window

If the share log has less than 8 × difficulty of work (launch, or a difficulty spike), the denominator is the total work in the log. Variance is higher; accounting stays fair.

Difficulty changes

Shares are never deleted. If difficulty rises, older shares can re-enter the window. If it falls, the window shortens.

Dust and output caps

Very small amounts below the dust threshold carry to a later block for that miner. Each coinbase has a maximum number of shielded outputs; overflow carries forward too.

See also ZIP-213 shielded coinbase and payouts & orphans.

Why shielded coinbase

• Miner rewards are created already in the shielded pool
• No 100-block transparent maturity for those outputs
• The pool never holds miner ZEC
• No mandatory transparent → shield hop after payout

Auditability

ZIP-213 requires shielded coinbase outputs to decrypt under the all-zero OVK (32 zero bytes). Recipient and amount are publicly auditable — like transparent multi-output coinbases — while funds are created already shielded. What you gain is custody and pool-membership privacy for the funds, not a hidden coinbase split.

Orchard today, Ironwood when the chain upgrades

On current mainnet, Sluicey builds multi-output Orchard coinbases. After NU6.3 / Ironwood activates, coinbase outputs move to that shielded pool. Prefer Unified Addresses with an Orchard receiver — Ironwood coinbase pays that receiver.

With TIDES

When the pool finds a block, TIDES computes each miner’s cut, then the coinbase creates those outputs (plus the operator fee) in one ZIP-213 transaction. Details: TIDES, payouts & orphans.

Non-custodial payouts

Rewards pay in the block coinbase (ZIP-213, zero OVK) — the pool never takes custody. There is no withdrawal queue: when Sluicey wins a block that stays on the best chain, your share is created to your Unified Address in that coinbase. Lifetime totals and the payout table on the dashboard count confirmed, non-orphaned wins only.

TIDES

TIDES keeps every share distinct so your cut is exact, not approximated by shifts.

Pool fee

Current mode: introductory rolling-24h tiers. The introductory schedule below is loaded from Sluicey’s versioned database policy:

Rolling 24h accepted hashrate	Pool fee
≥ 1,000,000,000 Sol/s (1 GSol/s)	0.25%
500,000,000–999,999,999 Sol/s	0.50%
< 500,000,000 Sol/s (500 MSol/s)	0.75%

Intro tiers use combined accepted work for the payout account across Sluicey pool endpoints. The rolling window is the preceding 24 hours—not “today” or a calendar day. Exact integer work comparisons select the tier at each boundary.

When the fee is fixed

At the first mining job for each new network height, Sluicey loads the versioned policy from Postgres, scores each account’s rolling work, and freezes the selected rate before building the coinbase. Same-height template refreshes reuse that snapshot. Policy changes take effect on the next height without restarting pool services.

The fee is deducted from your gross TIDES allocation. Gross payout, fee percentage, fee zatoshis, and net payout are retained in the block audit and the rate appears in your wallet payout email. Fee and miner outputs are created together in the same non-custodial ZIP-213 coinbase.

Standard policy after the introductory offer

When Sluice Gateway is released and the pool moves to standard pricing, public Stratum is currently configured for 1.75% and verified self-run Gateway traffic for 1.00%. The active policy shown above remains authoritative until that mode changes. Gateway docs

Orphans / lost races

Two valid blocks can compete at the same height. The network keeps one tip; the other is orphaned. That is a PoW property, not a Sluicey quirk. If our block loses the race, that coinbase never pays — same as any other pool that submits real blocks. The dashboard hides orphans from “recent blocks” and lifetime paid so you are not credited for a tip that did not stick.

Orphans are uncommon on mainnet at modest pool share, but they can happen. Share history is retained for TIDES either way; only the lost block’s coinbase is void.

Auditing a payout

Open the block on Zcashinfo from the dashboard, or look up your UA under pool stats. If something looks wrong, contact us with the height and your UA.

Why it exists

Large farms should not have to send every ASIC handshake across the public Internet to one Stratum. Gateway keeps a local ZIP-301 listener near your rigs, pulls work from Sluicey, and forwards solutions for verification and TIDES credit. The public pool still builds the multi-payee coinbase.

Fees

During the introductory offer, the wallet’s rolling-24h tier applies to combined account work. After standard pricing activates, public Stratum is configured for 1.75% and verified self-run Gateway traffic for 1.00%. Full payout context: Payouts, fees & orphans.

Status

• Coordinator APIs on the public pool: live
• Miner client: coming soon (thin ZIP-301 forwarder)
• Optional local Zebra beside the gateway (lower latency / validation): next
• Gateway client: available as a Docker bundle with an installer (below)
• Optional edge mode with a local Zebra or Zakura node: available, off by default

Practical tips when you run a gateway

1. Register your payout UA on Get started if needed.
2. Install and run the Sluice Gateway client near your ASICs once it is released — coming soon.
3. Install the Sluice Gateway bundle near your ASICs (see Install below).
4. Point ASICs at your local gateway Stratum (:3333).
5. Set ASIC Pool 2 to stratum+tcp://pool2.sluicey.xyz:3333 (Sluicey spare) — not sluicey.xyz:3333 and not a third-party pool.
6. Never expose a local node RPC to the public Internet.
7. Gateway must not hold miner spending keys. Prefer UAs with an Orchard receiver (Ironwood payouts).

Install overview: Sluice Gateway.