robinhood-chain-kit v0.7.0

0.7.0: the event name in the spec matches nothing on this chain

Robinhood Chain exists for tokenized equities, and this kit had nothing
about the one thing that makes a tokenized equity different from an
ERC-20. Corporate actions here do not mint or burn. The contract carries
a multiplier, raw balances stay exactly where they were, and the amount
a holder is shown changes underneath them.

The trap, and the reason to ship this at all: EIP-8056 names the event
TransferWithUIAmount. The deployed contracts emit TransferWithScaledUI.
Those hash to different topics —

0x37e7f0db430edc9dd31bc66f25f8449353aa0818f503b906747dd8f286cd3802
0x0226a2f5c1ae0e071aeec3d4ebafcefdc5c549be11f40ed27e76e802acccf374

— so a filter written from the spec matches zero logs, forever. It does
not throw and it does not look like a bug. It looks like a chain with no
tokenized-equity activity on it. Both constants are exported, and the
tests hash the signatures rather than trusting what I typed.

Multipliers are bigint end to end. A number cannot hold a uint256 ratio
exactly, and a figure that is quietly slightly wrong is the entire
hazard this module exists for. readScaledUiMultiplier fails closed: a
zero raw value makes the ratio undefined rather than enormous, and "we
cannot tell" is a different answer from "the multiplier is 1" — callers
that flatten those two are the ones who publish a split-adjusted figure
as if it were unadjusted.

compareScaledUiMultiplier reports direction and refuses to name a cause.
A split and a dividend adjustment both move it up; the event carries
nothing that separates them, and naming one would be a guess wearing an
API's clothes.

Also adds peer-to-peer settlement. A stock leg and a cash leg opposed
inside one transaction is a trade by construction, and no pool was
involved, which is why a swap-based index cannot see any of it. It fails
closed hard: exactly one leg of each, between the same two addresses, or
the transaction is left unclassified. The whole value of the output is
that a reported settlement really is one.

inferSettlementPrice carries inferred: true in the result type, where
a call site has to read it. No venue quoted that price. It is the ratio
of two amounts, and the parties may have agreed it hours earlier
off-chain at a level unrelated to any market. The count is a hard fact;
the level is a reconstruction.

The changelog now also marks 0.4.0 and 0.5.0 as developed but never
published. A reader on npm sees 0.3.2 jump to 0.6.0 and deserves to know
the middle two were real work that never shipped, not missing entries.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com