Infrastructure and API Agreements for Wallet and Digital Asset Businesses

By Hank FasthoffSeptember 18, 2026

Your customers may hold their signing keys while your application relies on a commercial provider to communicate with a blockchain network. If that provider suspends access, rejects requests, or withdraws a feature, customers may lose functions they expected your business to supply. The commercial risk depends on the provider’s commitments and the promises your business makes to its customers.

An application programming interface, or API, allows software systems to exchange requests and responses. A wallet may use an infrastructure provider’s API to obtain network information or submit a transaction signed elsewhere. Before committing to that provider, you should identify which customer functions depend on its services and compare those dependencies with the rights and remedies in the proposed agreement.

Permission to Offer the Product You Intend to Sell

Permission for employees to access a service and permission to incorporate that service into a customer product can differ. You should describe the proposed use in the order form, including whether customers interact with your application, receive provider data, or obtain direct access to the provider’s service. You should compare any restriction on resale or use for another person’s benefit with that description.

Alchemy’s terms illustrate why the definitions and restrictions should be read together. They recognize end users of applications built with the services, grant access for internal business purposes, and restrict resale and certain third party uses unless agreed in writing. That wording calls for confirmation that the permitted use includes your proposed delivery model. A negotiated provision can identify the allowed customer access and distribution without relying on an assumption about what a developer subscription includes.

The same review should address the information your product displays or retains. If your application combines provider data with customer records, you should establish whether the agreement permits storage, redistribution, and continued use after termination. Public availability of underlying blockchain records does not answer every contractual question about a provider’s enriched results, classifications, or other supplied information.

Capacity and Charges During Actual Customer Use

A subscription’s monthly allowance and its limit on requests during a short period describe different constraints. Alchemy’s throughput documentation measures capacity in compute units per second and evaluates the combined usage of applications in an account over a rolling window of 10 seconds. Requests exceeding capacity receive a 429 error response. A product can encounter those limits even when its monthly usage appears manageable. Alchemy’s terms also reserve the right to restrict requests that exceed the licensed volume or other throughput limits.

You should compare the purchased capacity with expected customer activity during concentrated demand. The order form can address which requests count toward the allowance, how usage is measured, and what happens when the application exceeds the agreed limit. A spending alert, an automatic increase in capacity, and a cap that stops further requests produce different consequences for your customers and your bill.

Quicknode’s terms, for example, provide for additional charges when included API credits are exhausted and place responsibility for monitoring usage and overages on the customer. Those provisions support reviewing the billing controls before launch. The agreement should also address disputed usage and charges arising from compromised credentials, including what records the provider will supply during an investigation.

A Response From the Provider and a Completed Transaction

For a transaction service, the parties should define the result the provider undertakes to deliver. Ethereum’s transaction submission specification describes submitting a transaction signed externally and returning its identifying hash. Its separate receipt specification describes a receipt containing execution results or a response indicating that no receipt was found. These are distinct stages that your product specifications and customer descriptions should recognize.

A contract might cover accepting a submission, forwarding it to the network, reporting its status, or providing an additional confirmation service. You should identify which of those functions you are buying and how the provider’s records will establish performance. A broad promise of successful transactions would require analysis of the network conditions and other events outside the provider’s control.

Information services require comparable precision. An API can answer a request while returning data that is too old or incomplete for the purpose your product serves. Specifications can address the supported networks, available historical information, update timing, and correction procedures. Your engineering team should identify the performance it requires so that those requirements can be included in the negotiated documents.

Service Credits and the Customer Commitments They Leave Unfunded

A service commitment’s value depends on its measurement rules and remedies. Alchemy’s terms state that service level commitments may be purchased for an additional charge under an order form, so you should confirm that the commitment applies to your subscription.

Alchemy’s Support and Service Commitment sets a 99.9% monthly availability target, subject to commercially reasonable efforts and exclusions. Credit eligibility requires missed commitments in two consecutive months. The credit is 10% of the affected API’s monthly charges for uptime of at least 99.0% but below 99.9%, or 20% for uptime below 99.0%. Credits must exceed $1 and apply only against future charges, with an annual cap of 5% of contract value.

Eligible credits are the exclusive remedy unless the terms of service provide otherwise. A request with supporting records must arrive by the end of the second billing cycle after the incident. Exclusions include suspensions described in the terms and factors outside Alchemy’s reasonable control, including outages affecting the underlying network. An interruption to your product therefore may fall outside the credit commitment.

If your business promises a customer reimbursement for an interruption, you should compare that obligation with the provider’s credit arrangement. A credit against a future infrastructure invoice may fund only a fraction of what you owe the customer. Negotiations can address that difference through the provider’s remedies, your customer commitments, or the commercial risk your business agrees to accept.

Suspension, Product Changes, and Notice

A provider can exercise a contractual suspension right even when its infrastructure is functioning. Alchemy’s terms reserve immediate suspension where use may create a security risk, violate laws or regulations, breach the agreement, or expose Alchemy or another party to liability. Negotiating notice and an opportunity to correct a problem therefore requires distinguishing an ordinary dispute from an emergency that warrants immediate action.

You should identify who receives suspension notices and what information the provider will supply about the affected activity. Where feasible, the agreement can require limiting a suspension to the affected application or credential and restoring access after the cause is resolved. A notice sent only to a departed developer’s account can leave management unaware that customer access is about to end.

Changes to supported networks and features can also affect the product you sell. You should negotiate notice periods appropriate to the time needed to replace a discontinued function, along with termination and refund rights where the provider withdraws an agreed capability. The agreement should identify which signed provisions control if an online policy changes during the subscription term.

Customer Data and Provider Use

The information a provider receives depends on the integration. You should document whether requests include customer identifiers, wallet addresses, transaction information, or other records, and whether the provider uses that information solely to supply your service or for additional purposes. That description allows counsel to assess the provider’s role and draft the business’s privacy disclosures around the actual processing.

When the Texas Data Privacy and Security Act applies to a controller and processor relationship, § 541.104 requires contractual processing instructions, specified processing details, and obligations addressing confidentiality, return or deletion, compliance information, assessments, and subcontractors. Under § 541.001, a controller determines the purposes and means of processing personal data, while a processor processes it on the controller’s behalf. The statute makes the classification depend on the facts of the particular processing.

A provision allowing the provider to develop aggregated or deidentified information should be assessed with its definitions and permitted uses. The agreement should identify any retention permitted for security or required by law. The agreement should support the privacy commitments your business makes, including the procedures for handling customer requests and obtaining information after a security incident.

Liability for the Losses Your Business Could Suffer

The largest foreseeable loss may substantially exceed the subscription fee. Quicknode’s terms exclude specified categories of damages, including lost profits, and state an aggregate liability limit of the greater of fees paid during the three months before the event giving rise to the claim or $20. The terms contain additional exclusions, so the cap does not establish that a particular claim is recoverable. Whether those provisions apply and are enforceable requires examination of the governing documents, facts, and law.

You should evaluate the proposed allocation against plausible failures in your product. A delayed display of transaction history, disclosure of customer information, and unauthorized use of a signing service can create different losses and involve different duties. Any negotiated exception or separate liability limit should identify the covered conduct and claims.

Indemnification also deserves separate treatment. A promise to defend specified claims brought by others can differ from a promise to compensate your business for its direct loss. The agreement should address which claims qualify, who controls the defense, and whether liability limits apply to the defense costs and resulting payments.

You should also assess the governing law and dispute forum before accepting the proposed remedies. Quicknode’s terms select Florida law and a Florida court forum, subject to their dispute resolution qualification, so a Texas business should account for the expense and practical demands of litigating elsewhere.

Leaving the Provider Without Abandoning Customers

Changing providers requires both contractual permission and a functioning replacement. You should identify the information, configuration records, and assistance your business will need, then address delivery formats, timing, charges, and continued access during the transition. Permission to retain information should be reconciled with deletion duties and restrictions on provider content.

A technical team can assess whether another provider supports the functions your product uses and test the proposed transition. The contract should assign cooperation duties and address the effect of termination on prepaid fees and unresolved claims. Before your business accepts customer obligations, its management should know which provider commitments support them and which risks the business will fund itself.