Supporting litho1… and 0x… addresses on the same account isn’t just a display choice
Address formats usually give away which ecosystem a wallet belongs to before anything else does. An 0x… string signals EVM compatibility. A different prefix signals a different chain family entirely, with its own tooling, its own wallet support, and often its own separate account underneath. Multi-chain users learn to recognize these formats quickly, because in practice each one usually points to a completely separate account, holding separate assets, with no real relationship to the others beyond being owned by the same person.
That separation is normally just accepted as how things work. A user with assets on an EVM chain and assets on a non-EVM chain isn’t managing one identity across two representations — they’re managing two unrelated accounts that happen to belong to the same person, with no shared history, no shared permissions, and no way for one to vouch for the other.
A multi-VM network raises a specific version of this problem: if a chain natively supports both EVM-style execution and non-EVM environments, does a user end up with two disconnected accounts again, just under one network’s branding — or is there actually one account underneath, capable of being addressed both ways?
The harder, more useful answer is the second one. On Lithosphere, an account can be addressed as either a litho1… or an 0x… string, but both point to the same underlying account rather than two separate ones that happen to coexist. The address format is a matter of which execution environment a given interaction is happening in, not a signal that a different account, with different history and different permissions, is now in play.
This matters most for anything that depends on continuity — identity, permissions, transaction history, reputation. If PPAL establishes an agent’s identity while it’s interacting through an EVM-style contract, that identity shouldn’t reset the moment the same agent’s workflow moves to a non-EVM environment on the same network. A unified account model is what makes that continuity possible: the address format changes to fit the context, but the account, and everything tied to it, stays the same underneath.
It’s a detail that’s easy to take for granted until you consider the alternative: a multi-VM chain that solves execution diversity but quietly reintroduces the same account fragmentation multi-chain users already deal with everywhere else. Supporting two address formats is the easy part. Making sure they both point to one coherent account, with one continuous identity, is the part that actually determines whether a multi-VM network feels unified or just looks unified from the outside.
Source: https://lithosphere.network/one-account-two-address-formats-why-thats-harder-than-it-sounds/
