feat: implement Nano (XNO) off-chain message signing (ORIS-001)

[cbrunnkvist]

Summary

Implement Nano Off-chain Message Standard to support the sign_message interface for the Nano (XNO) chain.
Example CLI output:

% cargo run -p ows-cli -- sign message --wallet test --message 'I am me.' --chain nano
3de8620fb30967916d3dc36cd09eba9a633d1678b986fbc31b70ae2834db25a898085bbce32b744aef42ed56b5c001ffebd5516e78c9f22c678dde2d8bdc150a

Implementation note

Raw byte signing is deliberately unsupported for Nano off-chain messages in order to prevent protocol confusion between block signatures and general signatures; the "NOMS" specification implemented by the PR is designed precisely to safely wrap off-chain text.

What this means for OWS

The standard OWS sign_message & CLI behaves identically to other chains for the end-user while securely conforming to the domain-separated Nano standard internally!

Technical notes

• Adheres strictly to the format set forward by ORIS-001, which serendipitously happens to comply with the guidelines proposed in PR docs: clarify sign_message contract across chains #185 ...
• No new cryptographic dependencies — reuses blake2 and ed25519-dalek (hazmat) from the original implementation.
• Handles padding boundaries, ensuring the maximum message length complies with the uint32 specification before yielding a SignerError (a potential source of bugs otherwise).

Testing

• Replaces the "unsupported" error-test with test_sign_message_noms
• All workspace tests pass (cargo test --workspace 268 total tests).

---

Note

Medium Risk
Changes cryptographic signing behavior for Nano CLI/API users; correctness depends on strict ORIS-001 compliance, mitigated by known test vectors.

Overview
Nano sign_message is implemented using the ORIS-001 NOMS format instead of returning an unsupported error. Payloads are built from the fixed magic header, a big-endian u32 length, and the message bytes; that blob is Blake2b-256 hashed, then signed with the existing Nano Ed25519-blake2b path (documented as intentional double-hash per the spec). Messages longer than u32::MAX fail with InvalidMessage.

Tests replace the old unsupported-error case with NOMS coverage: manual verify against the payload hash, a known vector (emoji message, pubkey, signature, address), and an empty message path.

^{Reviewed by Cursor Bugbot for commit a0c2fa8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

@cbrunnkvist is attempting to deploy a commit to the MoonPay Team on Vercel.

A member of the Team first needs to authorize it.

[cbrunnkvist]

done-done ™

[cbrunnkvist]

Well since you ask... 🧐 nope, that didn't work.

[cbrunnkvist]

N.b. I have downstream functionality waiting for this to be implemented

[0xultravioleta]

Hey @cbrunnkvist, this one's in good shape. No merge conflicts, and the checks that ran (Socket, semgrep) are green. The Vercel red is just the fork deploy-auth that trips on every external PR, you can ignore it.

One thing worth doing: the core build and test workflows (rust, node, python) don't show a run on your latest commit, so they need a re-trigger. A rebase onto main and a push will start a fresh run. Once those come back green I'll do the review and get it landed.

Appreciate the patience, I know you've got things waiting on this.

[cbrunnkvist]

@0xultravioleta

the core build and test workflows (rust, node, python) don't show a run on your latest commit, so they need a re-trigger. A rebase onto main and a push will start a fresh run. Once those come back green I'll do the review and get it landed.

If you say so..? Done.