[hippocampusSK]

OneKey users can connect Sui and send or swap on it.
Signatures returned by the wallet are checked to make sure they cover exactly the transaction the user was asked to sign.
Kept separate until it can be tested with the OneKey extension; it builds on the OneKey networks update.

Linear: API-3831

[hippocampusSK]

/dominion review

[ai-reviewer-towan]

PR review · published

Outcome: inconclusive. 1 finding: 1 low.

Open the published review for the TL;DR, findings and fixes.

Gate	Model	Status
logic	codex-cli gpt-6.1-sol	✅ passed
adversarial	codex-cli gpt-6.1-sol	⚠️ error
code-style-complexity	claude-code claude-opus-5-5	✅ passed

Run details

• Run: 134c820d-1977-457b-92e3-7236b3e0ba8a
• Head: 56d26d124536
• Base: 15a8aad354f5
• Check: review-runner

[ai-reviewer-towan]

TL;DR

This PR adds Sui connect, send and swap support for OneKey, and checks that signatures cover the requested transaction. The main issue is minor: the Sui signature check takes a needless base64 round-trip that can throw a raw decode error. The adversarial lane errored and its sandbox experiments produced no meaningful evidence, so that evidence is missing. Compatibility with the real OneKey extension is also untested.

This review is inconclusive. Some evidence is missing or failed, so it does not establish that the change is safe. 1 finding: 1 low.

• adversarial did not complete: assess adversarial experiments: adversarial experiments did not establish meaningful behavior and test-quality evidence

Low

Sui signature check uses a needless base64 round-trip

packages/wallet-extensions/src/onekey/helpers.ts:109 · code-style-complexity

The check that OneKey signed the requested Sui transaction is written as base64.encode(base64.decode(result.bytes)) !== serialized. The base64 decoder in @scure/base is strict, so any input it accepts re-encodes to the same string. The round-trip therefore adds no tolerance over a direct string comparison. Its only extra effect is a second, hidden failure path: malformed bytes throws a raw decode error instead of the OneKey signingError used everywhere else in this file. It also makes readers work out why the value is re-encoded, which hides the simple rule that the wallet's bytes must equal the requested bytes. The Tron and Stellar signers express the same check directly (txID !== requested.txID, signed.hash().equals(...)).

Fix: Compare the strings directly: if (result.bytes !== serialized) throw signingError(Chain.Sui, "OneKey signed a different transaction than the one requested");. Malformed and mismatched bytes then raise the same SwapKit signing error. The existing tests still cover the match and mismatch cases.

Review coverage and raw evidence

Reviewed head 56d26d124536688393ee6ba6c303d73ea447119d against base 15a8aad354f57b568673aebf35989edc9123b53c. Run 134c820d-1977-457b-92e3-7236b3e0ba8a.

logic — passed (0 findings)

Reviewed all five changed files, connection/error handling, signing integration, exports and test preservation. No concrete regressions found; no existing tests or guards were removed or weakened. Graph context was available but limited for dynamic/external dependencies; Argus coverage was partial. Tests were not executed, and real OneKey extension compatibility remains unverified.

adversarial — error (0 findings)

assess adversarial experiments: adversarial experiments did not establish meaningful behavior and test-quality evidence

Experiment probe-1 (behavior): passed, exit 0, 1948 ms.

Experiment probe-2 (test-quality): violated, exit 1, 1706 ms.

code-style-complexity — passed (1 findings)

I reviewed every changed file in the patch: the changeset, the OneKey Sui tests, helpers.ts, index.ts and types.ts. I compared the new Sui signer with the existing OneKey Tron, Stellar, Bitcoin and Near signers in helpers.ts. The Sui addition follows the file's existing pattern: a per-chain getXWalletMethods function, getProvider, a lazy toolbox import, connectionRejectedError/signingError, and a switch case in getWalletMethods. I found one simplification, a needless base64 round-trip in the signature check. The SUI_MAINNET constant also sits apart from the file's other constant, TRON_USER_REJECTED, but that is too minor to report. The Argus/Jev advisory pass was partial (coverage_incomplete): it produced no candidates, did not evaluate the .changeset markdown file, and omitted 173 reference files. Its gaps did not limit this review, because I read the needed source directly from the checkout.

Original specialist findings

F1 · low · code-style-complexity · packages/wallet-extensions/src/onekey/helpers.ts:109

Issue: The check that OneKey signed the requested Sui transaction is written as base64.encode(base64.decode(result.bytes)) !== serialized. @​scure/base's base64 decoder is strict, so any input it accepts re-encodes to the same string. The round-trip therefore adds no tolerance over comparing the strings directly. Its only extra effect is a second, hidden failure path: malformed bytes throws a raw decode error instead of the OneKey signingError used everywhere else in this file. Readers have to work out why the value is being re-encoded, which hides the simple rule that the wallet's bytes must equal the requested bytes. The Tron and Stellar signers express the same check directly (txID !== requested.txID, signed.hash().equals(...)).

Solution: Compare the strings directly: if (result.bytes !== serialized) throw signingError(Chain.Sui, "OneKey signed a different transaction than the one requested");. Malformed or mismatched bytes then both produce the same SwapKit signing error, and the existing tests still cover the match and mismatch cases.