Problem
People cannot easily tell how apps use their allowances, how much remains, or why an action is blocked. The wallet currently shows allocation outcomes, not current capacity or consumption.
Proposed experience
Add Usage & allowances to the wallet, answering:
- What resources do I have, and how much is left?
- Which apps or wallet/device functions received my allocations?
- What did my last action consume?
- When will capacity become available again?
- How do Lite and full personhood affect my entitlements?
Cover Statement Store publishing slots and their recipients (not the same as message count); PGAS balances/spending and separate claim opportunities; and Bulletin byte/submission quotas, allocation claims, and expiry.
Provide an overview, app breakdown, allocation details, and activity history. Explain expected costs in existing confirmations where possible and actual effects afterward.
Success criteria
- Values reflect the selected wallet, network, and current policy; no assumed fixed limits such as 50 slots.
- Known app/account attribution is visible; unknown attribution is labelled honestly.
- Lite/full comparisons use verified eligibility and actual network rules.
- Pending, failed, stale, and unavailable data are distinct from confirmed usage or zero balance.
- History survives reloads and states its coverage; earlier/external activity is not silently claimed as complete.
- Retries and multiple tabs do not double-count.
- Opening the dashboard cannot claim, renew, spend, or revoke resources.
- History contains no message bodies, uploaded content, or signing secrets.
Scope
Start in the experimental browser wallet using shared native-host accounting. Preserve existing allocation and confirmation behavior. The accompanying ADR will specify data sources, architecture, and delivery stages.
Problem
People cannot easily tell how apps use their allowances, how much remains, or why an action is blocked. The wallet currently shows allocation outcomes, not current capacity or consumption.
Proposed experience
Add Usage & allowances to the wallet, answering:
Cover Statement Store publishing slots and their recipients (not the same as message count); PGAS balances/spending and separate claim opportunities; and Bulletin byte/submission quotas, allocation claims, and expiry.
Provide an overview, app breakdown, allocation details, and activity history. Explain expected costs in existing confirmations where possible and actual effects afterward.
Success criteria
Scope
Start in the experimental browser wallet using shared native-host accounting. Preserve existing allocation and confirmation behavior. The accompanying ADR will specify data sources, architecture, and delivery stages.