Available, delegated and unclaimed rewards
Every token card carries a holding type. It records what state the balance is in, not just how much of it there is, and it is the reason one account can have three cards for the same token.
It used to be called availability
The field, the column and the filter now all read Holding type, and Unclaimed is now Unclaimed rewards. Nothing about what they hold has changed, and no card needs revisiting. You will still see availability in exported files and in the API.
The three types
| Holding type | What it holds |
|---|---|
| Available | The liquid balance sitting in the account, free to move or spend. |
| Delegated | Funds actively staked: bonded or delegated to a validator. |
| Unclaimed rewards | Pending staking rewards, plus anything in the unbonding or withdrawal period. |
The holding type is set when you create the token card and defaults to Available. Cards are badged throughout the app: Available in green, Delegated in orange, Unclaimed rewards in blue.
A Delegated card also records where you delegated, which is what lets its staked balance be read back from the chain.
An account that does not stake needs only Available cards. Fiat cards, on an exchange or a fiat account, have no holding type at all.
Running a validator
On Cosmos chains, an Unclaimed rewards balance also includes the commission the account has earned as a validator, where the address is one. Commission is owed to the validator but is not part of its own delegation, so it belongs with the pending rewards rather than with the staked balance.
Only the commission is counted, not the wider pool the validator owes its delegators. That pool is other people's money and is not this entity's to report. An address that does not run a validator is unaffected.
Why they are separate cards
Each holding type is a different on-chain balance. A validator's bonded stake is not the account's spendable balance, and pending rewards are neither.
Because a token card is what SimplyLedger reconciles, keeping them separate means:
- Balances are fetched per holding type. Creating a card reads the on-chain balance for that state specifically, not the account total.
- Reconciliation compares like with like. Each card is reconciled against the balance actually held in that state at the closing date. One combined card would never agree.
- The books show where value is. Staked capital and unclaimed rewards land in their own accounts rather than being indistinguishable from cash.
Holding type cannot be edited later
It is fixed when the card is created, and the card is what postings and reconciliations attach to. If you create a staked position as Available and only notice after posting against it, the fix is a new card and corrected postings, not a setting.
The delegation protocol on a Delegated card can be set or corrected afterwards. The holding type itself cannot.
Holding type when posting
Staking moves value between the cards rather than in or out of the account, and posting is where that movement is recorded.
When a token has more than one card in an account, the contra dropdown lists each one separately (Wallet A (Available), Wallet A (Delegated), Wallet A (Unclaimed rewards)), so you can post the movement between them:
| Event | Movement |
|---|---|
| Staking | Available → Delegated |
| Rewards accruing | into Unclaimed rewards |
| Claiming rewards | Unclaimed rewards → Available |
| Unbonding | Delegated → Unclaimed rewards, then → Available when it lands |
Elsewhere in the app the same information appears in the card's label, alongside the token and its address:
Ethereum (ETH) · 0xC02aaA39b2…c2 · DelegatedWhere an account has only one card for a token, the suffix is dropped; it is shown to tell cards apart, not as decoration.
Holding type in posting rules
A posting rule can target a holding type, so recurring staking activity categorises itself. If your entity stakes on a schedule, this is worth setting up once rather than categorising each reward by hand.
Next
Delegation protocols for the one thing a Delegated card needs beyond its holding type, or tokens and addresses for the reference data a token card is built on.