@ctrl-arcz/sdk; it is a hand-written port of the same protocol, and its source is
not published here.

Confirming a send

Picking a merchant

A bridge transfer returned
ParityVectorsTest.kt,
a byte-identical copy of the test
that runs in the Android project’s own suite. It contains no application code, no
keys and no endpoints. It is the whole of what the two implementations promise each
other, written as assertions rather than as a claim in a README.
What it actually asserts
The two that matter most are the least obvious. Addresses are compared with their
checksum case intact, because that is where the two sides drifted the first time.
And the stealth signing message is compared character for character, because one
character apart derives different keys from the same wallet signature, which loses
every box the other platform created.
Why this is checkable and not just stated
The vectors are never generated on the Android side. They come from this repository, and three things link the chain end to end:packages/sdk/scripts/gen-parity-vectors.tsderives every vector from the SDK’s own code. Nothing in it reaches a CSPRNG, so the output is the same on every run.packages/sdk/test/parityVectors.test.tsfails if the committedpackages/sdk/parity-vectors.jsonis not what the code produces right now. ChangeclaimCode.tsorstealth.tswithout regenerating and this repository goes red before anything reaches the other implementation.- The Android project’s
app/src/test/resources/parity-vectors.jsonis a copy of that same file. At the time this was written both weremd5 0c46c0edc9bb77d40f34d0663c318189, so the assertions above ran against these exact values.
Refreshing it
On the Android side the vectors are a file copy:app/src/test/java/xyz/ctrlarcz/domain/crypto/ParityVectorsTest.kt. It is kept
byte-identical on purpose: an edited copy would prove nothing.