feat(rpc): get block reward by hash by IzioDev · Pull Request #927 · kaspanet/rusty-kaspa

IzioDev · 2026-03-25T18:35:19Z

Given a block hash, returns its reward information.

Behaviors:

If b has not been merged (orphan), color will be unknown
If b has been merged and is part of the red mergeset, color is red
If b has been merged and is of the blue mergeset, get total paid reward (subsidy + collected fees)
- additionally, it b is a chain block / merging block, get red rewards

User persona: pool / bridge / solo miner

This is intended to replace complex systems (often inefficient) built on top of current RPC endpoints, specifically: GetBlocks.

Input:

pub struct GetCurrentBlockColorRequest {
    pub hash: RpcHash,
}

Output:

pub struct GetBlockRewardInfoResponse {
    pub header: RpcHeader,
    pub block_color: RpcBlockColor,
    /// guaranteed to be populated when block color != Unknown
    pub confirmation_count: Option<u64>,
    /// guaranteed to be populated when block color != Unknown
    pub merging_chain_block_hash: Option<RpcHash>,
    /// guaranteed to be populated when block color == Blue
    pub reward_amount: Option<u64>,
}

Example usage in Rust:

    // get block reward by block hash
    let result = client.get_block_reward_info(sink).unwrap().await?;

    println!(
        "confirmation count: {:?}, reward: {:?}, color: {:?}",
        result.confirmation_count, result.reward_amount, result.block_color
    );

Example usage in WASM:

    const rewardInfo = await rpc.getBlockRewardInfo({
      hash: "ab36f709e83bf6ba66e9516cbf02b9a9848a1b913e7c59cd5010e90928a27e22",
    });

    console.log(
      rewardInfo.blockColor,
      rewardInfo.confirmationCount,
      rewardInfo.header,
      rewardInfo.mergingChainBlockHash,
      rewardInfo.rewardAmount,
    );

IzioDev · 2026-03-25T18:41:46Z

+        match session.async_get_merging_chain_block_info(request.hash).await {
+            Ok(Some(info)) => Ok(GetCurrentBlockColorResponse { blue: info.is_blue }),
+            Ok(None) | Err(_) => Err(RpcError::MergerNotFound(request.hash)),
        }
    }


async_get_merging_chain_block_info intended to replace async_get_current_block_color. I cannot do full cleanup as a small quick pass as the bridge depends on async_get_current_block_color

What is the bridge using it for? I would only assume it'd need the info to also determine rewards.

It's used for nearly the same thing: after submitting a block, to track metrics of accepted block. But the logic looks wrong, after submitting it assumes that block is accepted if it's blue (one time check). So it should be revisited, but it's out of scope of the current task.

Used by:

rkstratum cpu miner (bridge\src\rkstratum_cpu_miner.rs):

bridge share handler (bridge\src\share_handler.rs)

IzioDev · 2026-03-25T18:42:55Z

+        let queried_blue_index = merging_ghostdag.mergeset_blues.iter().position(|hash| *hash == request.hash).ok_or_else(|| {
+            RpcError::General(format!(
+                "blue block {} was not found in merging chain block {} mergeset blues",
+                request.hash, merging_chain_block_hash
+            ))
+        })?;


unreachable?

IzioDev · 2026-03-25T23:09:54Z

+                    .checked_add(own_red_reward_output.value)
+                    .ok_or_else(|| RpcError::General("total reward amount overflowed u64 while adding own red reward".to_string()))?;


tempted to simply add

use saturating_add

it should never happen, or there is a reward bug, right?

IzioDev · 2026-03-25T23:10:15Z

+            .ok_or_else(|| {
+                RpcError::General(format!(
+                    "missing reward output {} in merging chain block {}",
+                    queried_blue_index, merging_chain_block_hash
+                ))
+            })?


tempted to assume unreachable

coderofstuff · 2026-05-24T03:42:39Z

+                    .checked_add(own_red_reward_output.value)
+                    .ok_or_else(|| RpcError::General("total reward amount overflowed u64 while adding own red reward".to_string()))?;


use saturating_add

coderofstuff · 2026-05-24T03:44:35Z

+
+kaspa.initConsolePanicHook();
+
+const BLOCK_HASH =


Wouldn't this be pruned?

Yes, but on the other hand, there is no interest (?) into listening for live rewards, i assume an executor of this script will want to put a hash parameter here.

Alternatively, the script could take argument from argv

coderofstuff · 2026-05-24T04:11:50Z

+        match session.async_get_merging_chain_block_info(request.hash).await {
+            Ok(Some(info)) => Ok(GetCurrentBlockColorResponse { blue: info.is_blue }),
+            Ok(None) | Err(_) => Err(RpcError::MergerNotFound(request.hash)),
        }
    }


What is the bridge using it for? I would only assume it'd need the info to also determine rewards.

coderofstuff · 2026-05-24T04:22:51Z

+            let queried_ghostdag = session.async_get_ghostdag_data(request.hash).await?;
+            let queried_coinbase = &queried_block.transactions[COINBASE_TRANSACTION_INDEX];
+
+            // only a chain block has its own red-reward coinbase output, as an exrta output


typo: exrta -> extra

coderofstuff · 2026-05-24T04:26:05Z

+
+        for child in self.get_block_children(hash).unwrap() {
+            if visited.insert(child) {
+                let blue_work = self.ghostdag_store.get_blue_work(child).unwrap();


better to get the value blue work value from header store

coderofstuff · 2026-05-24T04:27:19Z

+            }
+        }
+
+        while let Some(Reverse(SortableBlock { hash: decedent, .. })) = heap.pop() {


decedent -> descendant

coderofstuff · 2026-05-24T04:27:39Z

+
+            for child in self.get_block_children(decedent).unwrap() {
+                if visited.insert(child) {
+                    let blue_work = self.ghostdag_store.get_blue_work(child).unwrap();


use header store to get blue work here

coderofstuff · 2026-05-24T04:30:36Z


+    /// If block hash doesn't exist, returns Err
+    ///
+    /// For a given block hash, try to find its `MergingBlockContext`


This needs to be explained further. What is a MergingBlockContext? Add that documentation here.

IzioDev commented Mar 25, 2026

View reviewed changes

Comment thread consensus/src/consensus/mod.rs Outdated

IzioDev commented Mar 25, 2026

View reviewed changes

Comment thread rpc/core/src/model/message.rs Outdated

IzioDev commented Mar 25, 2026

View reviewed changes

Comment thread rpc/core/src/wasm/message.rs Outdated

IzioDev commented Mar 25, 2026

View reviewed changes

Comment thread rpc/service/src/service.rs

Comment thread rpc/service/src/service.rs

IzioDev force-pushed the feat/block-reward branch 2 times, most recently from a9242cf to ddcb3d7 Compare March 25, 2026 20:41

feat(rpc): get block reward by hash

485dd86

IzioDev force-pushed the feat/block-reward branch from ddcb3d7 to 485dd86 Compare March 25, 2026 23:06

IzioDev marked this pull request as ready for review March 25, 2026 23:06

Merge branch 'master' into feat/block-reward

0fa7ad5

IzioDev commented Mar 25, 2026

View reviewed changes

coderofstuff reviewed May 24, 2026

View reviewed changes

Merge remote-tracking branch 'upstream/master' into feat/block-reward

c429708

		.checked_add(own_red_reward_output.value)
		.ok_or_else(\|\| RpcError::General("total reward amount overflowed u64 while adding own red reward".to_string()))?;

Conversation

IzioDev commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

IzioDev commented Mar 25, 2026 •

edited

Loading