service-level agreement

Last Update : 22 June 2023

This Dfns Support and Service Level Agreement is issued under and forms part of the Dfns Cloud Service Agreement or other Dfns agreement which references this policy, and capitalized terms not defined have the meanings set forth in such Dfns agreement.

1. Target Availability

Dfns will use commercially reasonable efforts to make the Cloud Service available with an uptime of at least 99.90% of each calendar month (“Target Availability”).

Target Availability consists of the following services availability:
API availability – ability for Dfns to take commands, orders, requests and invoke appropriate functions immediately or queue them
Signature availability – ability for Dfns to produce new keys (and key based resources) and signatures Blockchain broadcasting availability - ability for Dfns to post transactions, messages, orders and contract invocations on blockchains (assuming overall blockchain availability)

Dfns is committed to providing the availabilities show below:

API Availability 99,95%
Signature Availability 99,90%
Blockchain Broadcasting Availability 99,90%

2. Uptime

Uptime is calculated based on the time, in minutes, that Users can connect to the Cloud Service.

3. Exclusions

The calculation of uptime will not include unavailability to the extent due to: (a) Customer’s use of the Cloud Service in a manner not authorized in the Agreement or Documentation, (b) general Internet problems, force majeure events or other factors outside of Dfns’s reasonable control, (c) Customer’s equipment, software, network connections or other infrastructure, (d) third party systems, acts or omissions, (e) Scheduled Maintenance or reasonable emergency maintenance or (f) blockchain availability; i.e. if all blockchain nodes are down. “Scheduled Maintenance” means Dfns’s scheduled routine maintenance for which Dfns notifies Customer at least fourteen (14) days in advance. Scheduled Maintenance will not exceed 3 hours per month and Dfns will use commercially reasonable efforts to perform Scheduled Maintenance only between the hours of 01:00 AM ET and 06:00 AM ET for a period of two (2) hours maximum.

4. Service Credits

If the Cloud Service fails to meet Target Availability in a particular month, Customer makes a written request within thirty (30) days after the end of such month, and Dfns verifies such failure, Customer will be entitled to a service credit based on the proportion of subscription fees for the affected Cloud Service in such month (“Service Credit”). For example, if Customer has an annual subscription, the proportion of subscription fees for any given month (the “Monthly Fees”) would be the annual subscription fees divided by 12. The Service Credit will be calculated as follows:

Uptime Service Credit (% of Monthly Fees)
98,00% - 99,90% 3%
96,00% - 97,99% 5%
<96,00% 7%

Dfns will apply each Service Credit to Customer’s next invoice, provided that Customer’s account is fully paid up, without any outstanding payment issues or disputes. Customer will not receive any refunds for any unused Service Credits. Service Credits for any month will not exceed seven percent (7%) of the Monthly Fees.

5. Exclusive remedies

Service Credits constitute liquidated damages and are not a penalty. Service Credits are Customer’s sole and exclusive remedy, and Dfns’s sole and exclusive liability, for Dfns’ failure to meet the Target Availability.

6. Support Definitions

Levels of severity:

  1. Show Stopper: Defect that prevents the Customer from using the Cloud Service.
  2. Critical: Defect that impacts a subset of functionality, but not the entire Cloud Service. Example: transactions on Cosmos are unavailable, but Ethereum is functioning normally.
  3. Medium: Defect that reduces functionality of the Cloud Service, but a workaround exists to accomplish the use case
  4. Low: Defect that is cosmetic or causes minor inconvenience.
  5. Beta: Defect in beta-testing environment. Features in beta are not subject to the same turnaround time as production.

Time from communication:

Time passed between the issue being reported by Customer and the issue being completely resolved by Dfns.

Support type:

  1. Defect: Any Cloud Service behavior, that is not described in the Documentation.
  2. Support Request: Any enquiry about the Cloud Service, requesting information, recommendations, examples, use cases for the Cloud Service.

7. Support Terms

Dfns is committed to providing the following support levels:

Support type Severity level Time from communication
Defect Show Stopper Best efforts to reach a resolution within 24 hours
Defect Critical Best efforts to reach a resolution within 3 days
Defect Medium Commercially reasonable efforts to reach a resolution within 1 week
Defect Low Commercially reasonable efforts to reach a resolution within 2 weeks
Defect Beta Commercially reasonable efforts to reach a resolution within 2 weeks
Support Request 1 Business day to initial response

8. Blockchain Integrations

Upon customer request, Dfns may, at its sole discretion, integrate new blockchain platforms into the Dfns Platform infrastructure. This is reserved for Pro Plan customers or above and generally requires the chain in question to have a well maintained open source SDK as well as publicly hosted validator nodes with proven robustness and high availability.  

Blockchain Integrations will be assigned a tier based on the overall demand for the chain in the market and the prominence of the chain itself taking into consideration metrics such as total locked value (TVL) and total stake committed to the chain.   Blockchain tiers are defined as follows:

Blockchain Tier Integration Level Example Chains
Tier 1 Full integration. Support for all wallet API endpoints and native NFT support. Full chain indexing. Dashboard support. Ethereum, Polygon, Binance Smart Chain, etc
Tier 2 Partial Integration. Support for broadcast transaction and retrieving native cryptocurrency balance. Signature and dashboard support. Tezos, Solana
Tier 3 Signature integration only. Customers may use the signature API and broadcast transactions themselves to the validators of their choice. Vechain