Consider moving away from elliptic

[bobbrodie]

It looks like elliptic is not going to address the low severity vuln. Even if it doesn't affect this SDK, it would beneficial to consider options.

Something we could consider, if it doesn't break backward compatibility whatsoever with tokens could be https://github.com/paulmillr/noble-curves. There's a shim that can help as well: https://github.com/soatok/elliptic-to-noble.

Let's weigh our options, including patching elliptic.

[swlodarski-sumoheavy]

@aharoitx For this SDK, @noble/secp256k1 is the best fit in my opinion because we only need Bitcoin-style secp256k1 signing. It is smaller, purpose-built, and faster to reason about than @noble/curves, which is a broader multi-curve package and would add unnecessary code and complexity for no functional gain here.

Also, @soatok/elliptic-to-noble is not a good long-term choice in this case. It is a migration bridge, not a final architecture, and it appears to be unmaintained for some time, with open issues that can block practical use. Keeping a bridge layer in production adds extra abstraction, maintenance overhead, and potential behavior mismatches versus using the native noble API directly. In short: direct @noble/secp256k1 usage is leaner, clearer, and safer for this Bitcoin-focused SDK.

I also ran a quick validation with @noble/secp256k1 and got very good results: all requests worked after migration, including flows using newly created tokens and existing tokens (created with elliptic).