Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

BUG - spo-stake-distribution

Open
  • Is something wrong?
#1,316 5 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
haskell
Domain
blockchain, cli

Research direction

Start by reproducing query spo-stake-distribution for the two pool hashes and compare the retirement and reward-address epochs described in the report. Trace the command's handling of stake-pool retirement and pending pool updates; done means the output consistently follows the project's intended epoch semantics for vote delegation.

Written by the indexing model from the issue text.

Description

While comparing some governance proposal numbers from DBSync with output from cardano-cli (10.13.1.0), it mostly matches down to the lovelace for all the different buckets I sum up for DRep and SPOs.

However, for the SPO tally, I noticed something strange regarding the always abstain status.

1.
Querying the cli query spo-stake-distribution I can see that pool with hash d68eed68381b65beb04fc7984dfa156c4dbf53c7911e900af6a535ef has the following data:
["d68eed68381b65beb04fc7984dfa156c4dbf53c7911e900af6a535ef",339284886531,null]
Ie it still has active stake according to the output, but is not marked as vote-delegated to always abstain.
It is set to expire in 601 (current epoch).
Its reward stake key is vote-delegated to Abstain and hasn't been deregistered or delegated to another DRep.

Most explorers have already marked the pool as retired.
Is the pool considered retired already, or is it first after the end of the current epoch?
DBSync also still has an entry for the pool in its pool_stat table for the current epoch.

Is the retiring epoch inclusive or exclusive?
If the stake is still active until the end of the epoch, shouldn't it then also still be marked as being vote-delegated to always abstain?

2.
Pool with hash 982f926165ebf6699df8704a16d11c9e13c88c4e02f63e3fe5af7181 has a pool update with a new reward address in epoch 599 set to go active in 602 (next epoch). The old rewards address was vote-delegated to CF, while the new one (for the update yet to take effect) is vote-delegated to Abstain.

Yet, in query spo-stake-distribution, it's listed as vote-delegated to always abstain, even though the update is not yet active.

Dominant language
Haskell
Stars
72
Forks
24
Avg merge
1d 5h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IntersectMBO/cardano-cli

All issues in IntersectMBO/cardano-cli

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.