Dashboard

FJARCODE FJAR

SHA3-256T SOLO 1% POOL FEE

SOLO SV1 + GBT

Updated 2026-10-07 09:56:52 UTC Node /FJARCODE:30.0.5/ ONLINE

24H → 0.00% $0.00030510

Pool Hashrate

300.82 MH/s

Miners / Workers

1 / 1

Network Hashrate

10.82 GH/s

Difficulty

437.55

Current Reward

25.00000000 FJAR

Height

219,532

Coin Connect

Connection details and official links

Home

Explorer

Github wallet

Discord

Extra

Notes

DATUM

Open DATUM Dashboard Gateway details

SOLO Protocol

SV1

SOLO Endpoint

POOL/TIDES Protocol

SV1

POOL/TIDES Endpoint

Not configured

Username

<WALLET_ADDRESS>.worker1

Merged Mining username

Password

SV1 + GBT (SOLO) Setup: Miner connects to the SOLO SV1 endpoint. The pool builds jobs from getblocktemplate (GBT), and with per-miner templates enabled each miner receives a dedicated template stream.

SV1 + GBT Flow: SV1 controls subscribe/authorize/submit while GBT provides fresh block templates from the node. Shares are validated in the same production pipeline as regular SOLO mining.

POOL/TIDES Setup: Miner connects to the POOL/TIDES SV1 endpoint shown above. POOL/TIDES runs as an independent runtime path and should be configured with its own port/domain in coin settings.

POOL/TIDES Flow: POOL/TIDES miners submit shares on SV1, jobs are sourced from GBT, and current block payout is estimated from the live POOL/TIDES share split. POOL/TIDES is not treated as SOLO mode.

Native Stratum V2

Protocol details

Transport: Native Noise_NX_Secp256k1+EllSwift_ChaChaPoly_SHA256 framing path with encrypted session negotiation.

Braiins: Tested interoperability path with compatibility handling for real-world Braiins Sv2 traffic patterns.

Compatibility: Channel-open accepts 0x10/0x11 and optional 0x1x variants; submit path handles 0x1A/0x1B/0x32 and optional 0x2x, with Braiins interoperability as a first-class target.

Validation bridge: Sv2 submits are mapped into the same core share checker used by production stratum paths.

SHA256d path: VERSION_MASK and V2 version-rolling integration support overt
ASICBoost-style version bit handling.

secp256k1-zkp Stratum V2 Guide Braiins Hashpower

DATUM Gateway Connect

Gateway-first setup guide

Pool Host

Pool Port

Pool Pubkey

Gateway Config Snippet

{}

POOL/TIDES Runtime

SV1 + GBT flow and payout behavior

POOL/TIDES Endpoint

Est. Block Payout

Mode

POOL/TIDES

Protocol: POOL/TIDES miners connect over SV1 while jobs are built from GBT.

Share split: Current block payout estimate is split by each miner's live POOL/TIDES share percentage.

Accounting: POOL/TIDES is independent runtime flow and is not treated as SOLO mode.

Refresh: Breakdown and payout values update with incoming shares and current reward changes.

RATUM PRIME ATTRIBUTION

RATUM Prime Disclaimer

Upstream attribution, license scope, and integration boundaries

Big thanks to iohzrd for building RATUM and making decentralized gateway operations practical for operators. This deployment follows upstream project boundaries and attribution practices.

Upstream codebase:
github.com/iohzrd/ratum

License and attribution: usage aligns with upstream licensing terms and keeps clear attribution to the original project.

No upstream code patches: this UI layer does not modify RATUM Prime source code.

Read-only integration: dashboard data is fetched from RATUM Prime API endpoints and rendered in this UI.

Operational boundary: SOLO and TIDES pool runtime remains separate from RATUM Prime service runtime.

Gateway intent: RATUM is used here to support resilient decentralized network operations while keeping pool domains clearly separated.

RTT Difficulty Explained

Quick guide for miners

RTT is an eCash target mechanism. The RTT KPI converts that target into a difficulty-style number (G/T) so it is easy to compare with normal network difficulty.

Higher RTT Difficulty means a harder target and fewer valid blocks on average.
Lower RTT Difficulty means an easier target and potentially more frequent valid blocks.
For a block to be valid, your share must satisfy the active RTT target as well as the normal block target.
RTT changes are normal when network conditions and template targets move.

Tip: if RTT Difficulty is above Chain Difficulty, RTT is the stricter gate for block validity right now.

Stats For Nerds

Health score

RPC transport

RPC auth

RPC timeout

RPC poll latency

Dash API RTT

RPC cache age

Stale detector

Chain

Connections

Node version

RPC updated

Node sync

Stratum V1

Stratum V2

0Health

0/5Capabilities

RPC latency trend -

Event cadence

Last event

ZMQ status

ZMQ topic

Reconnect sec

Min signal sec

RCVHWM

WS bridge

Stratum V2 runtime

Sessions (open/total)

0 / 0

Frames RX

Setup (ok/fail)

0 / 0

Channel open (ok/fail)

0 / 0

Submit (ok/fail)

0 / 0

Jobs / set_target

0 / 0

Node capability matrix

getblocktemplate

getblockchaininfo

getmininginfo

getnetworkhashps

submitblock

Runtime panel

App version

Python

Worker PID

Worker uptime

Event timeline

Worker Hashrate Limit Policy

Protection against abnormal worker hashrate spikes.

Status

DISABLED

Max Hashrate

0.0 H/s

Metric

MAX(EMA, WINDOW)

Ban Target

Ban Duration

48 hours

Hashrate limit policy is currently disabled. When enabled, workers above limit are auto-banned and disconnected for 48 hours.

197.6%

Effort

Pool Effort

Round 6.92K • 3h 32m

Overdue

3h 82.25%

Next Block Estimate

3h chance 82.25%

<0.1%

10m / All

Best 10m vs Best All

88.89 • 64.13 M

24H

Blocks Found 24h

Total 130,629 • 0.0% of total

Performance (Last 24h)

Loading chart

RTT Diff line is shown only for eCash/XEC when RTT data is available.

Miners

No miners in dashboard share stats yet for this coin. Miners appear here after first accepted/rejected share records are written.

Loading live miner data...

Accepted and Rejected Shares

How share validation works and how miners can reduce rejects

Accepted means a submitted share met the current share difficulty target and passed validation. Rejected means the share did not pass one or more checks.

On this pool, Accept Always is disabled. Share quality is enforced by the active difficulty target, so invalid or stale shares are rejected instead of being force-accepted.

Common reject reasons

Share hash does not meet the assigned share target (difficulty too low).
Stale share after a new job arrived (high latency or delayed submit).
Duplicate share already submitted for the same job.
Invalid nonce or malformed submit payload.

How to reduce rejects

Use the closest stratum endpoint and stable low-latency network path.
Keep miner software and firmware updated.
Avoid overloaded rigs and verify clocks and power tuning are stable.
Use correct worker credentials and avoid duplicate worker sessions.

Tip: a small reject rate can happen naturally, but persistent spikes usually indicate network delay, unstable tuning, or a worker configuration issue.

Miner Notice

Important compatibility information

Warning

Round Shares

Accepted diff_actual shares since latest found block

Latest Blocks

Loading latest blocks