**Context** Today, identity ownership has historically relied on `frame_system` `sufficients` references. A sufficient reference allows an account to stay alive without requiring a provider-backed existential deposit (ED). **Problem** This behavior allows identity accounts to survive without truly meeting the normal account liveness rules. In practice, an identity account can get special persistence semantics that differ from the intended runtime policy. We want identity accounts to follow standard account economics: an existing identity should still require an account that respects existential deposit constraints. **Why this change** Switching identity lifecycle references from `sufficients` to `consumers` makes identity persistence depend on normal provider/account rules instead of “self-sufficient” survival. This prevents identities from implicitly bypassing ED expectations. **Proposed change** 1. On identity creation, increment `consumers` (not `sufficients`). 2. On identity deletion/removal, decrement `consumers` for new identities. 3. Keep backward-compatible handling for legacy identities still carrying `sufficients`: decrement `sufficients` when present. 4. In owner-key change flows, clean up old keys with the same legacy/new split (`sufficients` first if present, otherwise `consumers`). **Expected outcome** - Identity-linked accounts no longer rely on sufficient references for persistence. - Existing identities must effectively satisfy normal account existence constraints (including ED-related behavior). - Legacy identities continue to be handled safely during transition. **Acceptance criteria** - New identities do not increase `sufficients`. - New identities cannot be fully drained with `transfer_all`; ED remains. - Legacy identities are removable/key-change-safe without refcount underflow or leaks. - Integration test added for “identity cannot transfer all funds to zero balance.”