Overview

Fireblocks supports cryptographic Proof of Address signing for the TRUST (Travel Rule Universal Solution Technology) Network.

When interacting with TRUST for Travel Rule compliance, VASPs must prove ownership of blockchain addresses involved in a transaction. Fireblocks enables this by creating a secure typed message signing transaction using its MPC infrastructure.

This article explains:

• Why Proof of Address is required
• How the Fireblocks flow works
• Supported assets
• How to retrieve and submit the signature to TRUST

For full API implementation details, see the Developer Portal guide.

What is Proof of Address?

Proof of Address is a cryptographic signature proving that your organization controls a specific blockchain address. TRUST requires this verification before accepting Travel Rule data associated with that address. Without this proof, TRUST cannot confirm address ownership.

How the TRUST proof flow works

When a counterparty initiates a Travel Rule interaction through TRUST:

1. TRUST requests proof: TRUST generates a UUID via its CreateAddressOwnership endpoint.
2. You create a signing transaction in Fireblocks: Fireblocks generates a typed message signing transaction tied to:
   • Your vault account
   • The asset
   • Your TRUST prefix
   • The TRUST UUID
3. Approval and MPC signing: The transaction follows your workspace approval policy. Once approved, Fireblocks signs the message using MPC.
4. Retrieve the signature: You retrieve the TRUST-formatted signature via API.
5. Submit to TRUST: You send the signature to TRUST’s Bulletin Board /verify endpoint.

The proof is successful once TRUST responds with VALID.

Supported assets

Proof of Address is supported for:

Important limitations

Only permanent addresses can be proven

Proof of Address applies only to the permanent address of a vault account. This is the address derived at derivation index 0. Other deposit addresses cannot be used for TRUST proof verification.

Transaction statuses

Proof transactions follow standard Fireblocks transaction states.

In most cases, the proof transaction completes immediately after creation.

Security considerations

• Fireblocks uses Typed Message Signing, not Raw Signing.
• Typed signing mitigates the risk of signing unintended or malicious payloads.
• All signing operations follow your existing approval policy.
• No additional permissions are introduced.
• TRUST is an external protocol and is not operated by Fireblocks.

High-Level API flow

1. Create Proof Transaction

POST /v1/screening/travel_rule/trust/proof_of_address

Returns:

{
 "transactionId": "uuid",
 "status": "COMPLETED"
}

2. Retrieve Signature

GET /v1/screening/travel_rule/trust/proof_of_address/{transactionId}

Returns:

{
 "transactionId": "uuid",
 "status": "COMPLETED",
 "signature": "encoded_signature"
}

3. Submit to TRUST

You must POST the signature to TRUST’s verification endpoint:

POST /v1/verify

Example payload:

{
 "chain": "ETHEREUM",
 "type": "ETHEREUM_EOA",
 "signature": "0x...",
 "prefix": "yourcompany",
 "uuid": "trust-uuid",
 "address": "0x..."
}

Expected TRUST response:

{
 "result": "VALID",
 "invalidReason": ""
}

Developer implementation

For full TypeScript SDK implementation examples, polling logic, and signature formatting details, see:

Developer Portal → TRUST Proof of Address API

The SDK method used is:

fireblocks.travelRule.createTrustProofOfAddress()

fireblocks.travelRule.getTrustProofOfAddress()

SDK package:

@fireblocks/ts-sdk (v14+)

Related resources

• Fireblocks Transactions API
• Fireblocks Webhooks
• TRUST Network documentation