Summary
dim_dz_shred_distribution_2z_pool stores one row per (subscription_epoch, reward_mint) and does not record which distribute role that journal plays. Onchain a leaf can have two: a publisher journal and a separate client journal.
From ValidatorLeafState in programs/shred-subscription/src/processor/common.rs:
separate_validator_client_journal — None when the publisher journal is itself seeded by 2Z — it plays both publisher and client roles and the caller omits the separate client journal account from the instruction.
So for 2Z one journal serves both sides, and the reward pool a client team is paid from is the same one its validators are paid from. For a non-2Z token the client rewards can come from a different journal with its own rewards_amount() and its own accumulators.
Impact
Bounded today. The client-team figures on /dz/shreds/rewards are 2Z-denominated, which is the case where one journal covers both roles, so they are exact. The gap bites as soon as a non-2Z client figure is wanted, or if a reader assumes the stored pool row describes both roles for USDC or wSOL.
Current state: 70 epochs indexed for 2Z, 45 for USDC, 38 for wSOL, all with a single row per (epoch, mint).
What is needed
Record the journal's role alongside the mint, so a pool row can be resolved as publisher, client, or both, and the reward math can pick the right one per branch.
Context
Raised in review on #787, alongside #790.
Summary
dim_dz_shred_distribution_2z_poolstores one row per (subscription_epoch, reward_mint) and does not record which distribute role that journal plays. Onchain a leaf can have two: a publisher journal and a separate client journal.From
ValidatorLeafStateinprograms/shred-subscription/src/processor/common.rs:So for 2Z one journal serves both sides, and the reward pool a client team is paid from is the same one its validators are paid from. For a non-2Z token the client rewards can come from a different journal with its own
rewards_amount()and its own accumulators.Impact
Bounded today. The client-team figures on
/dz/shreds/rewardsare 2Z-denominated, which is the case where one journal covers both roles, so they are exact. The gap bites as soon as a non-2Z client figure is wanted, or if a reader assumes the stored pool row describes both roles for USDC or wSOL.Current state: 70 epochs indexed for 2Z, 45 for USDC, 38 for wSOL, all with a single row per (epoch, mint).
What is needed
Record the journal's role alongside the mint, so a pool row can be resolved as publisher, client, or both, and the reward math can pick the right one per branch.
Context
Raised in review on #787, alongside #790.