ComplianceClientImpl class
Sanctions screening for connected (non-WaaS) wallet transactions before they're signed — a Dynamic embedded wallet is already screened server-side during signing, so this domain refuses rather than re-screens those. Instances share the root client's state. NOTE: not yet thread-safe.
- Implemented types
Properties
Methods
-
install(
DynamicClient client) → void -
override
-
isExternalWalletScreeningEnabled(
) → bool -
Whether the environment expects connected (non-WaaS) wallet transactions to be screened for sanctions before signing. No network request — reads straight off the already-loaded project settings.
override
-
noSuchMethod(
Invocation invocation) → dynamic -
Invoked when a nonexistent method or property is accessed.
inherited
-
screenBitcoinTransactions(
String accountAddress, String networkId, String? psbt, String? recipientAddress) → Future< ScreenTransactionResponse> -
Screens one Bitcoin transaction's destination against the environment's sanctions providers before an external (non-WaaS) wallet signs it — pass either psbt or recipientAddress, whichever the caller already has. networkId is REQUIRED here: dynamic-js-sdk resolves it from the wallet provider's getActiveNetworkId when omitted, and this DSL has no such round trip yet (no network-management surface — see WalletProvider's own docstring). See screeningBitcoinChainId for how it collapses to mainnet/testnet for the screen itself while still being recorded unchanged for audit. Deliberately ONE transaction per call — see screenEvmTransactions's doc for why.
override
-
screenEvmTransactions(
String accountAddress, String? to, String? networkId) → Future< ScreenTransactionResponse> -
Screens one EVM transaction's destination against the environment's sanctions providers before an external (non-WaaS) wallet signs it. Deliberately ONE transaction per call, not a batch: the IR's forEach step is side-effect-only — there is no way to accumulate one verdict per iteration into a returned list, unlike dynamic-js-sdk's own transactions[]/results[] shape — a caller screening several transactions calls this once per transaction. senderAddress is always accountAddress: dynamic-js-sdk's optional override to screen a different sender is dropped as a power-user knob nothing else in this DSL exposes.
override
-
screenSolanaTransactions(
String accountAddress, List< String> serializedTransactions) → Future<ScreenTransactionResponse> -
Screens one or more already-serialized Solana transactions' destinations against the environment's sanctions providers before an external (non-WaaS) wallet signs them, in a single request that yields one verdict for the whole batch — the wire contract already takes a list here, unlike EVM/Bitcoin's one-call-per-transaction shape, so no batching deviation is needed. Callers serialize their own platform Solana transaction objects first (base64 or base58) — this DSL has no Solana transaction type of its own to accept.
override
-
screenTransaction(
String chain, ScreenTransactionContext context, String? networkId, String? senderAddress) → Future< ScreenTransactionResponse> -
Screens a connected wallet's transaction for sanctioned addresses before you prompt it to sign, and returns the verdict. context carries the chain-specific payload the server extracts addresses from — see screenEvmTransactions/screenBitcoinTransactions/screenSolanaTransactions for the common chains, or build a ScreenTransactionContext by hand for anything else. networkId is recorded for audit only and never changes the verdict.
override
-
toString(
) → String -
A string representation of this object.
inherited
Operators
-
operator ==(
Object other) → bool -
The equality operator.
inherited