Skip to content

Add wallet screening overview page #429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
maxbayuk wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add wallet screening overview page #429

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,7 @@
"group": "Safety & Security",
"pages": [
"security/compliance",
"security/wallet-screening",
"security/unsupported-exchanges",
"security/bounties",
"security/mev-protection",
Expand Down
42 changes: 42 additions & 0 deletions security/wallet-screening.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
title: "Wallet Screening"
description: "Learn how Relay screens wallet addresses for sanctions and illicit activity across every flow."
---

Relay screens every transaction for sanctioned and high-risk wallet addresses. This page covers which flows are screened, which sources are used, what happens on a match, and how to request evidence of a screen.

## Which flows are screened

Screening applies uniformly across all Relay flows — bridges, swaps, and deposit-address transactions — whether initiated via the API, SDK, or Relay-hosted UI. There are no unscreened flows.

For every transaction, all addresses involved are screened:

- The depositor (the wallet sending funds)
- The recipient (the wallet receiving funds on the destination chain)
- The refund address (`refundTo`), if one is specified
- The recovery address (`recoveryAddress`), if one is specified
- Any fee recipient addresses

Screening is performed both at quote time and again at fill time, before funds are forwarded to the destination.

## Which lists are screened against

Every address is screened against four sources in parallel:

- **TRM Labs**
- **Chainalysis**
- **ZeroShadow**
- **Relay's internal blocklist**
Comment on lines +24 to +29

@greptile-apps greptile-apps Bot Aug 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Conflicting screening-provider disclosures

This page presents TRM Labs, Chainalysis, ZeroShadow, and the internal blocklist as the sources used for every address, but the existing Compliance page identifies HackBounty, Chainalysis, and the internal blocklist for the same transaction-screening function. Partners therefore cannot determine which providers actually participate in production screening. Confirm the authoritative provider set and make both pages consistent, or explicitly explain why the lists cover distinct workflows.

Artifacts

Provider-list validation source

  • The authored Node script reads the requested Git revisions and compares the named public screening providers, with the takeaway that it detects the provider-list contradiction.

Provider-list validation before the Wallet Screening page

  • Executed output for `b4cf2b4^` shows Compliance naming Chainalysis, HackBounty, and the internal blocklist while Wallet Screening did not yet exist, with the takeaway that there was no second list before this PR.

Provider-list validation after the Wallet Screening page was added

  • Executed output for `b4cf2b4` shows the unchanged Compliance list and the new TRM Labs, Chainalysis, ZeroShadow, and internal-blocklist Wallet Screening list, ending with `contradictionConfirmed: true`.

Documentation rendering attempt blocked by schema validation

  • Mintlify local-preview output shows it could not serve the documentation because `/deposit-addresses/v2/get/responses/200` fails OpenAPI validation for a missing `$ref`, with the takeaway that UI rendering and video capture were blocked outside these two pages.

View artifacts

T-Rex Ran code and verified through T-Rex


A wallet is blocked if any source flags it. Compliance operators can additionally apply a manual ALLOW or BLOCK override with a documented reason.

## What happens when there's a match

- If any address is blocked at **quote time**, the quote fails and a `400` error is returned.
- If any address is blocked at **fill time**, the fill is aborted and funds remain in the protocol. Funds can be withdrawn by the depositor address.

## Evidence of screening

Screening results are persisted on Relay's side (TRM results are retained for 6 months). Each screening result records the verdict from every source individually, so a record can show which list (if any) triggered a block for a given address.

If a partner requires evidence of a specific screen, Relay can provide the screening record for the relevant address(es) on request through your support channel.
Loading