Add wallet screening overview page

[maxbayuk]

Adds a Wallet Screening page under Safety & Security, documenting which flows are screened, the four screening sources, what happens on a match, and how partners can request evidence of a screen. Content reviewed internally before publication. Placed in the sidebar directly after Compliance.

[maxbayuk]

Source thread:
https://relayprotocol.slack.com/archives/C06H5HM5F5K/p1786624182672609

[greptile-apps]

Greptile Summary

This change adds a Wallet Screening page and exposes it in the Safety & Security navigation. The new page conflicts with the existing Compliance page about which third-party providers are used for transaction screening, so partners may receive inconsistent compliance information.

The reported withdrawal-path concern was disproved by the documented execution flow: an unfilled order preserves the depositor's Hub balance, which can be reclaimed through the Allocator-authorized withdrawal process. The conflicting provider disclosure remains to be reconciled before merge.

Confidence Score: 4/5

Not ready to merge until the public screening-provider disclosures are made consistent.

The provider discrepancy was directly reproduced by comparing the parent and current documentation revisions. The separate withdrawal concern was checked against the Hub, Allocator, Depository, and failed-order documentation and was contradicted by that flow.

Files Needing Attention: security/wallet-screening.mdx needs reconciliation with security/compliance.mdx; docs.json only adds navigation for the new page.

T-Rex Logs

What T-Rex did

• I ran the authored documentation-contract check for the blocked-fill recovery path and confirmed that an unfilled order leaves the depositor's Hub balance intact and withdrawal is possible via the Allocator-authorized path, contradicting the claim that the page directs depositors to an unavailable recovery path.
• I produced a proof for a posted P1 finding and attached the review details showing provider-list validation before and after the Wallet Screening page was added, plus a rendering attempt blocked by schema validation.
• I confirmed that the parent revision had no security/wallet-screening.mdx and that the executed check exited with status 0 while capturing custody, Hub, withdrawal, and failed-order evidence, with no code or documentation changes aside from the authored validation script.
• A second finding-proof for a posted P1 finding was produced.
• I compared the before/after provider-lists results and noted the contradiction and rendering blocker, logging that the documentation server never started.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Public compliance pages disclose contradictory wallet-screening providers

   • Bug
     • The newly added Wallet Screening page publicly states that every address is screened against TRM Labs, Chainalysis, ZeroShadow, and Relay's internal blocklist. The existing Compliance page publicly identifies HackBounty and Chainalysis plus the internal blocklist instead. Both pages describe the same transaction screening function, but differ on which third-party providers participate.
   • Cause
     • The PR added security/wallet-screening.mdx without reconciling its definitive four-source list with the pre-existing provider list in security/compliance.mdx.
   • Fix
     • Confirm the authoritative production screening sources, then update both public pages to use one consistent provider list (or explicitly explain distinct scopes if the lists intentionally cover different screening workflows).

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Add wallet screening overview page" | Re-trigger Greptile}

[greptile-apps]

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.

_{Ran code and verified through T-Rex}