The problem is not ignorance; it is fragility. Even if you use a hardware wallet, securely store your seed phrase, and follow best practices, a single wrong signature is often catastrophic. This, along with the difficulty of tracking and prosecuting thieves, makes self-custodied assets an exceptionally attractive target for attackers.

To address those shortcomings, most prominent figures in the crypto space started advocating for multisig wallets. Instead of relying on a single device that can be compromised, multisig splits control across multiple independent signers, preventing a single point of failure. But as was demonstrated multiple times in the past, this approach has holes if implemented naively.

Drawing on lessons we learned so far, I want to lean into Starknet’s security-first culture to push self-custody further. In the rest of this post, I’ll outline my proposal, walk through a small MVP, and explain how it could fit into the broader user experience. I’m sharing this to get feedback and to find people who are interested in helping turn this project into a reality.

Challenges of Self-custody

Currently, the majority of users self-custody their crypto holdings in Externally Owned Accounts (EOAs). These are simple private keys managed by software or hardware wallets. The main line of defense preventing users from signing malicious transactions is parsing them into a human-readable format, sometimes including monitoring for suspicious behaviors. But even if both of these defences were very mature, which they are not, EOAs have a huge problem: a single malicious software or firmware upgrade from a compromised supply chain would be catastrophic. There would be no guarantee that what you see on the display is what you truly sign, rendering such detection efforts useless.

Smart contract accounts are another option. They add programmability and can enable more secure setups, such as multisig accounts. As mentioned earlier, these distribute control across multiple independent signers but remain vulnerable if not implemented with care. Take ByBit heist, for example: three experienced signers were tricked into losing a $1.5 bilion, because all three looked at the same compromised interface. With this setup, the theoretical security of “many keys” effectively disappeared, making their supply chain a single point of failure.

Another challenge in securing user wallets is accounting for human fallibility. Re-examining the ByBit case, the signers were not only approving transactions through the compromised software interface, but also confirming them on their hardware devices. Those devices were never compromised, yet all three signers still failed to intervene. Thing is, humans are not equipped to detect malicious intent in complex transactions, especially when that complexity is compressed into a few cryptic lines on a tiny hardware wallet screen.

Solution

To restore confidence in self-custody, we need a security layer that sits alongside the user’s wallet rather than inside it. It must be operated independently to limit the risk of supply chain attacks and hold part of the signing power so a compromised wallet can’t act alone. Most importantly, it must assume humans will miss what attackers hide in complex call data and make “unsafe signatures” harder to approve by default.

The closest solution I’ve found so far is Ready Wallet’s multisig, which lets you use a Ledger as a second factor. Ledger is operated independently and holds part of the signing power, but human fallibility is left unaddressed, as hardware wallets do little to protect users from signing malicious transactions. Add the fact that adoption would be held back because users need to buy a separate device, and this becomes a very hard sell.

Instead, I believe we are now uniquely positioned to introduce a new type of second factor. One that provides strong transaction analysis and eliminates adoption problems. I am, of course, talking about AI-assisted cosigner, an agent working tirelessly to analyze transactions on the user’s behalf. Hosted as a cloud service that can be linked to wallets easily, the security of self-custody can be improved considerably without added friction.

MVP

I developed and deployed a web service, named Multisig Cosigner, to demonstrate the idea described above. It integrates with Ready Wallet, both the browser extension and mobile versions.

The current MVP is deliberately simple, but it already delivers one important property: users are not worse off for using it. Every outgoing transaction is forwarded to Multisig Cosigner, which displays the raw call, limiting the risk that a compromised wallet UI or a simple mistake will lead to loss of funds.

The usage is straightforward:

1. The user creates an account, which generates a public/private keypair for the Multisig Cosigner.

2. In the Ready Wallet, the user creates a multisig account and sets a Multisig Cosigner as a second signer.

3. Multisig Cosigner listens for outgoing transactions and presents them to the user for approval.

For exact steps on how to use Multisig Cosigner, see the video below.

There is, however, an important design caveat in the demo. If the user configures the multisig as 2-of-2 with Multisig Cosigner, it is no longer true self-custody: the platform could, in theory, block signatures. In a production setup, the safer pattern would be a 2-of-3 wallet, where the user keeps one key offline as an override in case the service is unavailable or compromised. The video uses 2-of-2 only because it is the simplest way to show the mechanics.

Finally, this MVP does not yet include any AI-based transaction analysis. It is a thin, transparent co-signer that surfaces raw transaction data and enforces the “separate, independent signer” property. Its value today is to prove how easily such a service can plug into the Starknet ecosystem, and to provide a clear foundation on which smarter, AI-assisted policies can be layered later.

Roadmap

Here’s my current working plan for moving this project forward. The roadmap prioritizes usability and real-world integrations with existing wallets and services, while leaning on off-the-shelf AI capabilities rather than building new models from scratch.

Phase 1: A simple service that integrates with a third-party wallet and allows users to approve outgoing transactions manually. It displays raw transaction data to the user and allows them to approve or reject signing them. The goal is to test the market and see whether end users, and consequently wallet vendors, would perceive this service as valuable.

Phase 2: A production-ready platform where users can create cosigners and integrate with an existing wallet vendor on the mainnet. The platform cannot be bypassed during signature, shows signature requests to the user, and allows the user to approve or reject the transactions.

Phase 3: An AI-agent analyses the transaction for suspicious behavior before forwarding it to the user for the final approval.

Phase 4: A platform moves beyond Starknet, leveraging threshold signature schemes to implement multisig-like functionality on chains that do not support smart contracts. The service provides an API that allows third-party wallets to integrate with it easily.

Phase 5: A formally verified policy engine that approves transactions based on spendint limits, whitelisted recipients, or trusted smart contracts, automatically approving routine transactions without user involvement.

Existing Solutions

I considered a couple of approaches from different ecosystems, but all fell short of my expectations. This was mostly because they only target enterprise customers, do not support Starknet, or because they do not do any transaction analysis:

• Silent-shard-snap: Used to support Snap for MetaMask, but is now targeting enterprise customers only. No transaction analysis.

• Safeheron: Requires a dedicated wallet. Enterprise only. No transaction analysis.

• Cosigner: Gnosis Safe only. Enterprise only. AI transaction analysis.

• FailSafe GUARD: Supports Safe (Gnosis Safe), Fireblocks, and Squads. Enterprise only. AI transaction analysis.

Conclusion

Self-custody is often pitched as a better alternative to using custodians, but today’s tooling shifts a lot of security responsibility onto regular users. Hardware wallets, multisig setups, and better UX can all help, yet the ByBit heist and similar incidents show that a single compromised interface and a few hasty signatures are still enough to wipe out fortunes. Starknet’s account abstraction and mature multisig support give us a rare chance to do better.

An AI-assisted co-signer is one concrete way to seize that opportunity: a second factor that lives outside the wallet, understands what a transaction is actually doing, and raises a flag when something looks wrong. The MVP and roadmap outlined here are early steps toward that vision, although there is plenty left to figure out. If this direction resonates with you, as a wallet developer, security researcher, or Starknet user, I’d love your feedback and collaboration to help turn safer self-custody into a default.