Dfns · Rate Limits

Dfns Rate Limits

The Dfns API enforces per-application and per-organization rate limits to protect the signing and wallet infrastructure. Limits are applied per API path/method class and are heavier on read (list/get) endpoints than on sensitive mutating endpoints that require User Action Signing (transfers, signature generation, policy changes). Specific per-endpoint request-per- second/minute values are governed by the commercial agreement and are not publicly reconciled in this artifact.

Dfns Rate Limits is the machine-readable rate-limit profile for Dfns on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests and signatures.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Wallets, MPC, Key Management, Digital Assets, and Web3.

4 Limits Throttle: 429
WalletsMPCKey ManagementDigital AssetsWeb3Rate LimitingQuotasThrottling

Limits

Requests Per Application application
requests
see provider documentation
Aggregate request limit per registered Dfns application, varies by tier.
Requests Per Organization organization
requests
see provider documentation
Aggregate request limit across an organization's applications and users.
Signature / Transaction Throughput organization
signatures
see provider documentation
Throughput of signing and transaction-broadcast operations; may be shaped per blockchain network and commercial tier.
Read Endpoints application
requests
see provider documentation
List/get endpoints (wallets, transfers, transactions, events) carry higher limits than mutating endpoints.

Policies

Tiered Limits
Rate limits scale with the commercial agreement and deployment model (SaaS vs. dedicated).
User Action Signing Gate
Sensitive mutations (transfers, signature generation, key/policy changes) require a User Action Signing challenge/complete flow, which naturally throttles automated abuse of those endpoints.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on HTTP 429 responses.

Sources