mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekay
e081ccef5f
A fungible transfer says move N units of an asset to an account. A
security crossing cannot be said that way: the destination has to run
the register before the position exists there — whether the recipient is
verified, what act this is (an arrival is not a mint), and whose clock
the position brings with it.
None of that fits BridgeTransfer, whose layout is frozen and whose
Amount is a uint64 — too small for an eighteen-decimal position above
about 18.4 tokens. So SecurityCrossing is a sibling message with its own
domain tag rather than a widening of that one. The frozen digest stays
frozen, and a fungible attestation can never be replayed as a security
one because the tag they commit to differs in the first bytes of the
preimage. That property is asserted, not assumed.
Two fields carry what the destination cannot ask the source for:
Identity the holder's ONCHAINID on the SOURCE register. The register's
clocks belong to the person, not the key, and the
destination has no way to look it up.
Acquired when the holder first received on the source. Without it an
arriving position anchors to now, and a holding period a
crossing resets is a holding period a crossing washes off.
Both are zero where the source had none — an honest absence the
destination weighs as it likes, rather than a default that reads as an
identity of zero.
Quantity is 32 bytes big-endian for the full uint256.
VerifyAgainst takes the expected group key as an argument, following the
fix already recorded on the fungible verifier: reading the key off the
struct being verified answers "was this signed by whoever signed it",
which an attacker's own key satisfies. Asserted here too.
Every field is bound — each of the seven, mutated one at a time, stops
the signature verifying.