This is the Metal evidence profile for IVMS data. It does not replace the
complete IVMS101 data model, encrypted record exchange, retention policy, or
legal validation performed by the responsible virtual asset service providers (VASPs).
Standalone precompile fields
The Travel Rule precompile at0xF9 accepts these fields in packed binary form:
A successful call returns the recovered signer as a left-padded 32-byte EVM
address. Malformed input, a structural mismatch, or an invalid signature returns
the zero address. The precompile does not check a registry or credential proof.
The caller must reconstruct the digest from the payment and IVMS root, compare
the recovered address with an authorized signer, and apply its expiry and replay
rules. It must not trust a digest supplied unchanged by the transaction sender.
Schema version 1
Schema1 requires exactly five commitments:
The IVMS verifier treats each entry as an opaque
bytes32 commitment.
Raw values remain offchain. The precompile checks the count and root; it does
not open the commitments or require their values to be nonzero. A policy proof
that inspects a field must agree with the record producer on its encoding and
commitment scheme.
IVMS root
The root is an ordered packed hash reduced into the BN254 scalar field:1 with any count other than five is malformed.
MIP410 payload commitment
MIP410 commits an optional private record together with the payment and its identifiers. The code usesFi for the VASP role in identifiers such as
recipientFiBindingCommitment.
Field commitments
Every field is committed under its own salt, derived from a per-payment seed:f is the field’s index in the table below. Text is UTF-8 packed into 31-byte
limbs from the start, and each field has a fixed limb count; over-length text
is rejected rather than truncated. A field is absent exactly when all its limbs
are zero, so presence needs no flag. For the same reason, text cannot contain a
NUL byte, and the party type encodes a natural person as 1 and a legal person
as 2.
Payload schema version 1
The payload commits 28 fields: eleven per party, then the two VASPs, then four ISO 20022 payment identifiers. Party fields list the originator’s index first and the beneficiary’s second. In the IVMS101 column they belong to the party’soriginatorPersons or beneficiaryPersons entry. In the ISO 20022 column,
P stands for Dbtr (originator) or Cdtr (beneficiary).
Fields
0 to 23 form the travel-rule record. Fields 24 to 27 form the
payment identifiers.
The tree
1 in recordRoot is the record schema version, and the 1 in idsLeaf
is the payment identifiers profile version. A payload under any other version
fails to open. recordRoot is zero when no record accompanies the payment,
that is, when every record limb is zero. The evidence leaf is fixed to zero.
The current format carries no credential or screening-attester evidence in
that slot.
Where the commitment is checked
The initiation proof recomputes the commitment from the payload plaintext, taking the payment leaf from its own public inputs, and exposes the commitment as a public input. The pool rejects a zero commitment and stores the commitment on the hold. It supplies the stored value to the resolution proof and the recipient VASP’s wrapped policy proof. Reclaim uses the hold’s deadline and requires no proof. The plaintext travels offchain in two sealed halves. The memo is sealed to the recipient’s shielded address and carries the note opening, the payment effect, the nonce, and the deadline, with the payload commitment in its cleartext header. The 2230-byte institutional artifact is sealed to the recipient VASP’s registered messaging key by ECDH with that key. It carries the payload seed, the payment identifiers, the travel-rule record, the sender VASP’s identifier, and the sender VASP’s Schnorr signature by its messaging key overPoseidon2(DOMAIN_PAYLOAD_AUTH, commitment).
To authenticate a received payload, the recipient VASP assembles its two halves
against the onchain hold. It refuses the payment’s content when the
memo disagrees with the hold, when the payload does not hash to the hold’s
commitment, when the sender VASP is absent from the pool’s institution registry,
or when its signature fails. The signature authenticates the signer, never the
truth of the record’s values.
Reading fields in a policy
A policy reads only the fields it screens. It checks the payload’s four leaves against the commitment, binds the record or identifier commitments to their leaf, and opens each field it needs with that field’s salt and limbs. Fields it does not open stay hidden inside the proof. A policy binds the record only when the record root is nonzero. For example, the reference threshold policy requires a nonzero record root before it permitsAccept for a *USDZ payment of 50 *USDZ or more. It checks
record presence without opening individual fields. It places no record condition
on Reject, which stays the VASP’s decision. A rejection can therefore proceed
without the institutional artifact, provided the recipient has the payment
opening needed for resolution. The wrapper still requires the VASP’s
authorization of either outcome.
No X.509 VASP credential proof, screening-attester verdict, or in-circuit
record signature is part of a MIP410 proof. The evidence leaf is reserved for
them.
Delivery acknowledgements
MIP410 has no built-in record-delivery acknowledgement format or receipt check. A VASP can require delivery evidence through a custom policy, which must bind that evidence to the payment. Accepting a payment does not by itself prove that the record was decrypted or retained.Privacy and trust boundary
The standalone precompile checks the five-field structure and recovers a signer. MIP410 verifies the payload commitment and the configured private policy, with a separate VASP authorization in the wrapper. The chain receives no complete IVMS record and does not establish that a committed identity value is accurate. The sender and recipient VASPs remain responsible for:- validating and retaining the IVMS101 record;
- selecting a lawful encrypted transport;
- confirming that the committed values match the exchanged record; and
- applying the rules required by their jurisdiction and operating model.
Payment messaging
How institutions exchange payment instructions and Travel Rule records.
Roles and authorization
See how wallet and institution keys authorize MIP410 payments.
Signing and EIP-712
Look up the Metal typed-data domains and digest rules.
MIP410 API
Look up MIP410 structs, entrypoints, and policy controls.