I ran some quick benchmarks comparing wax vs hive-js on Node.js 20 (linux x64, 8-core server):

This is where wax (through wasm) dominates:

The secp256k1 wasm vs pure-javascript gap is massive - this alone justifies the switch.

Unfortunately... crossing wasm boundary hurts:

For trivial operations like vestsToHp (which is just BigInt(vests) * BigInt(fund) / BigInt(shares)), the ~12.7us per call is almost entirely overhead from crossing the javascript-to-wasm boundary (converting javascript objects into a format that wasm understands, calling into it, and converting the result back).

A pure javascript implementation would be sub-microsecond.

Is it possible for helper functions that don't benefit from wasm (asset math like vestsToHp/hpToVests/hbdToHive, simple conversions), providing javascript-native fast paths that would eliminate the one area where hive-js still outperforms wax?
That's not a common because usually not called frequently and not taking long (absolute time), but this matters for batch-processing use cases, like idk, processing large data exports where these conversions happen a lot.

The crypto operations should obviously stay in wasm (the 500-1000x speedup is incredible). But is it still possible for the utility/math layer to be pure JS with zero wasm boundary crossings?

The serialization gap (34x) is likely harder to address since it's fundamental to the wasm architecture, but for most real apps it's still plenty fast at 17K ops/s as the bottleneck is always network or signing.