checkBeneficiaryAllowlist()

function checkBeneficiaryAllowlist(params, locConfig): ValidationIssue[];

Checks whether a beneficiary address is permitted by the SDK’s LOC config.

• If beneficiary.value is configured, the address must match (case-insensitive).
• If locBeneficiaryAllowList is non-empty, the address must appear in it.

This is a synchronous check — no RPC calls. It operates on config values provided at SDK construction time.

Parameters

Parameter	Type
params	BeneficiaryCheckParams
locConfig	BeneficiaryCheckConfig

Returns

ValidationIssue[]

Remarks

Never throws on a malformed beneficiaryAddress or allowlist entry: this check participates in the SDK’s validate* contract (invalid input is a domain outcome, not an infrastructure failure), so comparisons use addressesEqual’s plain case-insensitive string comparison rather than toAddress’s checksum-validating one. A malformed beneficiaryAddress simply fails to match a well-formed configured value and is reported as ValidationErrorCode.BeneficiaryNotInAllowlist or ValidationErrorCode.BeneficiaryMustUseConfigured like any other mismatch — it does not need a distinct “invalid format” outcome there because beneficiaryRules, the in-repo caller, already rejects a malformed beneficiaryAddress earlier via validateAddress. A caller invoking this exported check directly, without that upstream guard, still gets a reported issue instead of a thrown error.

The configured side (beneficiary.value or an allowlist entry) has no such upstream guard anywhere — beneficiaryRules only validates the caller-supplied address, and the public export bypasses it entirely — so this check validates the configured side’s shape itself, before any comparison. addressesEqual does no hex/length validation, so without this guard two identically-malformed strings (a malformed configured value and an equally malformed beneficiaryAddress) would compare equal and this check would silently report no issue, treating a non-address as an allowed beneficiary. A malformed configured value or allowlist entry is reported as ValidationErrorCode.AddressInvalid — distinct from the ordinary-mismatch codes above — on every call, regardless of what beneficiaryAddress is, the same way the pre-addressesEqual throwing comparison surfaced it on every call a malformed config was live for.