Imagine this: you receive DOT through Telegram, then send that DOT directly to a GitHub user, who later controls and uses those assets with an EVM wallet.
And all of this happens on JAM.
JAM does not prescribe what kind of account system users must use. So what wallet should you use to interact with JAM? And what kind of RPC should you use?
The answer is that you can directly use most Web3 wallets, or even avoid using a traditional Web3 wallet altogether. Applications can also support different RPC specifications.
More importantly, this is not some kind of third-party custodial service. You are interacting directly. You can still natively transfer assets, swap, manage liquidity, play games, and more.
This is not account abstraction either. Account abstraction addresses the question of “how should an account be controlled?” Ownership abstraction goes one step further and asks: why should assets have to be tied to a particular account system at all?
This is the native Ownership Abstraction capability provided by JamScript.
It expresses ownership as a self-describing cryptographic proof that can be verified in place. The chain does not need to prescribe in advance that users must use SS58, EVM, Ed25519, or any other fixed account format. It only needs to know one thing: can you prove that you have the right to perform this operation?
As long as an ownership proof can be verified deterministically, it can become a new Ownership type.
This also means that wallets no longer define ownership.
EVM wallets, Polkadot wallets, Solana wallets, Matrix, and even future post-quantum wallets can all simply be different ways of proving ownership.
In traditional blockchains, changing the cryptographic system used by user accounts—for example, migrating to post-quantum cryptography—usually involves upgrading the broader account system and ecosystem.
With Ownership Abstraction, we can simply add a new Ownership type.
You can experience this in Locus, an asset service built on JAM:
You can sign in to Locus with a Matrix account, or with Web3 wallets such as EVM, Polkadot, and Solana wallets, and natively perform on-chain operations including transfers, swaps, and adding liquidity.
In the production version, we hope to support even more types:
-
Matrix: Supported. The next step is mainly to improve user experience and security. One thing to note is that around 2% of Matrix accounts cannot currently be discovered.
-
Telegram: From the perspective of Ownership Abstraction itself, there are no obvious technical limitations, and usage outside Telegram is unaffected. Inside Telegram, however, the platform has policy restrictions on non-TON blockchain applications, so additional ways of using it within Telegram still need further exploration.
-
Email: Ownership based on cryptographic credentials such as OpenPGP. The real-world use cases may be limited, so this is more of an experimental, cypherpunk-style form of support.
-
GitHub: GitHub is better suited to CLI-based usage, which should work particularly well for Agents and machine-payment scenarios. A GitHub username is still an identity identifier, although it satisfies the discoverability requirements of Ownership Abstraction, so some user-experience trade-offs still need to be considered.
You can already experience the current version of Locus running on the MiniJAM testnet: