A Native Wallet for a Maturing Ecosystem

Movement is one of the most ambitious bets in the Move ecosystem. Built around the Move Virtual Machine and the resource-oriented Move language originally developed at Meta for Diem, Movement is a sovereign Move Layer 1 focused on stablecoin settlement and yield. Since its inception, Movement has been hardening that base layer and growing the DeFi stack on it.

A maturing ecosystem eventually needs infrastructure it owns. Movement users had long reached the network through third-party, multichain wallets; Motion is the next step. Launched in April 2026, Motion is the first-party, self-custodial wallet built for Movement by Movement and shipped as a Chrome extension. Single-ecosystem by design, it trades multichain breadth for fewer friction points: sending, swapping, and signing without fighting the wallet or second-guessing the network.

Self-custody was the promise from day one: keys are generated and held locally, encrypted on the device, and never transmitted. Security was a fundamental launch requirement, not a post-ship cleanup. Before v1.0 reached anyone, Motion went through independent review by two firms, OtterSec and Sherlock, with the full reports published. This case study covers the Sherlock engagement, an adversarial assessment of the part of a wallet that contract audits never touch.

Pen Testing the Browser, Not the Blockchain

In smart contract security, the threat model is the contract. With a wallet, it is everything around it: the browser tab, the scripts a page loads, the messages between an injected provider and a background process, and the split second a user spends reading an approval popup before signing. A wallet's whole job is to sit between a hostile page and a user's keys, so this engagement was built around penetration testing rather than a conventional code read: simulating a malicious script or a compromised dApp, then proving each broken boundary with a working exploit. That adversarial lens is the only reliable way to surface the failures module-by-module review misses.

One Wallet, Several Worlds

A wallet like Motion, a Chrome Manifest V3 extension that exposes the Aptos AIP-62 wallet standard to dApps, is really several execution contexts that have to cooperate: the web page, the provider the page can see, an isolated bridge, and a background process that holds the keys. The vulnerabilities that matter most are not in any single component; they live in the seams between those contexts, several of which are open by design to any script sharing the page. The question was not whether the cryptography was correct, but whether the wallet's assumptions about who it was talking to could be broken. Many of the highest-impact findings answered yes.

Where the Risk Lived

Five themes carried the most weight: isolation between the page and the wallet's own contexts; whether the account a user selects is the one a dApp actually connects to and signs with; whether a malicious dApp can influence what a user sees and approves; whether locked functionality stays locked; and whether an external app can impersonate the wallet. These were the invariants the assessment set out to break.

A Collaborative Review Loop

Movement chose Sherlock's collaborative audit model, with Defsec leading the review and penetration testing end to end.  His application security and penetration-testing background made him a strong fit for a browser-extension wallet, where the hardest bugs live between web contexts, approvals, and key custody. 

The work continued through remediation. Defsec reported each issue, the Motion team opened a fix PR, and each fix was re-reviewed to confirm the vulnerability was closed cleanly.

The review started from the wallet’s trust graph. Defsec mapped the contexts Motion spans, from dApp page scripts to the background process holding the keys, then walked each channel with one question: what does the receiver assume about the sender, and can that assumption be enforced? That edge-by-edge model surfaced the findings, which were then proven against the real extension in a live browser, with an attacker tab beside a victim dApp.

That approach fit the architecture. The highest-value findings came from reasoning across extension contexts, approval flows, provider objects, and signing surfaces, then pressure-testing those assumptions by hand.

The audit ran from March 24 to April 1, 2026, with the final report delivered April 16. Scope covered the full extension: the background process, injected provider, crypto core, dApp connection layer, and every approval surface a user touches.

What the Assessment Found

The assessment identified six high-severity findings, alongside a set of mediums and lower-severity items. What matters most is what happened next: every actionable finding was resolved before launch and the rest formally acknowledged, with nothing left unaddressed. The character of those findings stands out just as much. As the report put it, the most impactful issues were not cryptographic failures but security-boundary and trust-model issues, the kind that emerge specifically in browser-extension wallets.

Under the Hood: The Core Findings

The three highlighted Highs tell the same trust-boundary story from different angles: the page deceiving the provider, the page rewriting the provider, and a dApp deceiving the user.

When the Page Pretends to Be the Wallet (High)

Motion's injected provider shares the web page's JavaScript context, and its only filter on incoming messages checked that the event came from the same window, which always passes for any script already on the page. With no shared secret to tell a genuine wallet event from a forged one, a co-resident script, an injected ad, a compromised library, could forge an account-change event and set the connected account to an attacker's address. The provider would fire the dApp's callback, and the dApp would route every subsequent transaction to the attacker, while the wallet's own logic ran correctly the whole time. Motion resolved it by treating page-delivered events as untrusted hints and verifying state against the background process's authoritative record, which a page script cannot forge.

Seeing One Message, Signing Another (High)

Motion built its structured sign-message by joining labeled fields, address, application, chain ID, message, nonce, with newline separators, and never checked the message or nonce for embedded newlines. A malicious dApp could supply a message containing newlines and fake field labels, injecting extra fields into what actually gets signed. The popup showed the benign message, while the signed string carried attacker-chosen lines a verifier would treat as authoritative: the user sees "Buy NFT," the signature commits to "transfer 1000 MOVE to the attacker." What makes it instructive is that the cryptography is flawless: the signature is valid for exactly the bytes the wallet handed it, and the flaw is the human-versus-machine reading gap inside the message format, the same class of bug that recurs in EIP-712. The fix rejects carriage-return and newline characters in those fields.

Beyond the Headline Three

The same lens reached past these two vulnerabilities. The assessment also hardened the wallet's locked state, where approval screens could render on a wallet the user believed was sealed; its in-memory handling of key material, where a cached password and mnemonic could surface in a memory dump; and the precision of its swap math. Every actionable finding was closed before launch.

Hardened Before Launch

Motion is the wallet layer of Movement's push toward a sovereign Move L1 stack, and they treated security as a requirement, not an afterthought, bringing in two external firms before v1.0 shipped. The Sherlock engagement was the security intelligence layer, focused on the seams a contract audit never reaches.

The findings that mattered most were not cryptographic breaks but trust-model failures, the kind that only surface when a researcher reasons about the system as an attacker would. Every one was resolved before launch and verified through a fix-review loop. Wallets are judged by the worst thing an attacker can make them do, and Motion launched having had that surface pressure-tested and hardened.

Special thanks to Defsec for leading the audit and penetration testing, and for lending his expertise to this writeup.

Secure Your Protocol, Wallet, or App with Sherlock

Sherlock is the complete lifecycle security provider for leading Web3 teams, covering smart contracts, applications, wallets, infrastructure, and live systems. Tell us what you are building and where the risk lives, and we'll help scope the right review.

Contact Our Team

‍