internal/compliance
library
Classes
-
ComplianceClient
-
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.
Implemented by ComplianceClientImpl; hosts can substitute this interface in tests.
-
ComplianceClientImpl
-
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.
-
ComplianceExtension
-
Registers ComplianceClientImpl on the root client. Access it through client.compliance.
-
ScreenTransactionBtcContext
-
Exactly one of psbt / recipientAddress should be provided.
-
ScreenTransactionContext
-
Chain-specific transaction payload; exactly one field should be set (dynamic-labs sdk-api-core's ScreenTransactionRequestContext, an inline nested object upstream with no schema of its own — see this DSL's own convention for such gaps, e.g. WaasPolicyRule.valueLimit). Deliberately narrow: only the three chains screenEvmTransactions/screenBitcoinTransactions/screenSolanaTransactions cover (evmTransaction/btcTransaction/svmTransaction) are modeled — stellarTransaction/suiTransaction/tronTransaction are out of scope for this pass. Use screenTransaction directly with a hand-built context for anything else.
-
ScreenTransactionEvmContext
-
The envelope destination, absent for contract deployments.
-
ScreenTransactionResponse
-
The screening verdict: whether the transaction is allowed and, when it is not, the addresses that caused the block. Undecodable payloads and provider errors fail open to allow, server-side.
-
ScreenTransactionSvmContext
-
One screening request can cover several Solana transactions at once, in one verdict.
-
WaasPolicyRule
-
One rule on a wallet-, signer-, or account-policy-Layer (dynamic-labs sdk-api-core's WaasPolicyRule) — shared verbatim by request and response bodies (the response's own WaasPolicyLayerResponseRule differs only in making ruleId required, not worth splitting into a second model here). Omit ruleId to create a new rule (the enclave mints one); pass an existing id to update it in place. Deliberately does NOT model contractAbi (Array
