When the Collateral Is Compute: What a GPU-Backed Loan Actually Owns

Private credit has long financed physical equipment such as aircraft, ships, factories, telecom equipment, vehicles and industrial machinery. GPU finance adds a different combination of risks: the collateral is physical, but its productivity and value depend on a rapidly changing compute network, its location, configuration, customer contracts and operating state. The relevant question is therefore which assets and rights secure the financing, rather than whether the package contains equipment described as NVIDIA GPUs.

On 28 August 2026, Bullish announced a $100 million stablecoin-based liquidity facility for USD.AI to support financing against high-performance computing assets. USD.AI describes its borrower loans as non-recourse and secured against the underlying GPU infrastructure, with capital providers receiving exposure to income-producing compute assets. USD.AI: USD.AI Secures $100M Bullish Facility The scale is becoming material. In its August recap, USD.AI reported:

• $281.8 million of lifetime deployed capital;
• 16 financings across 13 borrowers;
• $15.3 million deployed into a QumulusAI NVIDIA B300 cluster;
• $7.5 million deployed against a commissioned NVIDIA B200 deployment for Corvex;
• and more than $400 million of sUSDai supply.

USD.AI: August Recap—$100M Facility and sUSDai ATH The transaction is interesting partly because it sits at the intersection of:

• equipment finance;
• private credit;
• AI infrastructure;
• data centres;
• receivables;
• digital assets;
• and secondary liquidity.

But the core DaDepo question is simpler:

What exactly is the collateral when the lender says it is lending against compute?

The answer is not merely: NVIDIA GPUs. A GPU-backed loan can depend on an entire asset chain.

Identify the equipment and its changing value

Start with the obvious layer. A GPU server exists physically. It has:

• manufacturer;
• model;
• serial number;
• configuration;
• memory;
• installed components;
• purchase date;
• invoice;
• shipping record;
• location;
• condition;
• and current operator.

That makes GPU finance look like equipment finance. A lender can theoretically take security over identified hardware. But a GPU cluster is unusual collateral. It is:

• valuable;
• mobile;
• modular;
• technologically sensitive;
• operationally dependent on other infrastructure;
• and subject to rapid depreciation.

The useful asset is therefore not simply: GPU: B300. It is:

• Which B300?
• Owned by whom?
• Located where?
• Installed in which chassis?
• Connected to which data centre?
• Running under which contract?
• Encumbered by which lender?

Identity is the beginning of credit control.

Suppose a borrower owns 576 identical GPUs. A portfolio spreadsheet says 576 NVIDIA B300 GPUs. That is useful for capacity planning. It is not enough for secured lending. The lender may need unit-level or server-level identity. For example:

Record item	Value or state
Asset ID	GPU-SRV-00452
Manufacturer	NVIDIA / OEM integration
GPU model	B300
Server serial	ABC123
Rack	R12
Data centre	Facility X
Owner	SPV 7
Lien	Lender A
Status	Commissioned

If the equipment moves, the record should move with it.

A mortgage lender can assume that a commercial building may remain useful for decades. A GPU lender faces a much shorter technology cycle. Value can change because:

• a new GPU generation is released;
• performance per watt improves;
• memory capacity changes;
• networking standards change;
• customer demand shifts;
• AI workloads evolve;
• supply shortages disappear;
• or resale markets become saturated.

The useful economic life can be much shorter than the physical life. That means the financing structure needs to align:

The loan tenor should not exceed the expected economic life of the collateral.

USD.AI’s published standard model describes straight-line amortisation over approximately 36 months, designed to align repayment with GPU depreciation and revenue generation. USD.AI: GPU Financing That is a classic asset-backed finance problem. The asset amortises. The debt should generally amortise too.

A GPU can have several values at the same time. For example:

• OEM purchase price;
• delivered cost;
• installed cost;
• book value;
• market resale value;
• orderly liquidation value;
• forced-sale value;
• replacement cost;
• and income-based value.

Those are different objects. A server purchased for $300,000 may not be worth $300,000 in enforcement two years later. A replacement-cost spike during a shortage may not translate into a resale bid. A GPU generating attractive compute revenue may be worth more in operation than as dismantled equipment. A proposed structured evidence record should therefore store valuation context.

Connect the SPV, data centre, customer contracts and utilisation

USD.AI describes its financing model as asset-level and non-recourse. Its public materials describe first-priority security over GPU servers and associated SPV assets. That introduces a legal wrapper. A simplified structure may look like:

Capital provider → Loan → GPU-owning SPV → GPU servers → Compute revenue.

The SPV can help isolate:

• asset ownership;
• financing;
• collateral;
• cash flows;
• and borrower risk.

But the lender still needs to know:

• does the SPV legally own the equipment;
• was title transferred correctly;
• are purchase invoices in the SPV’s name;
• are there competing liens;
• where is the hardware physically located;
• and can the secured party control or recover the equipment?

The SPV is a legal object. The GPU is a physical object. The loan is a financial asset. They must remain separate.

A GPU has little economic value sitting in a warehouse. Its value is maximised when it is installed inside an operating data centre with:

• power;
• cooling;
• racks;
• fibre;
• network fabric;
• security;
• monitoring;
• and operations.

That means the location matters. A lender may need to know:

• facility;
• rack;
• power allocation;
• cooling capability;
• access rights;
• data-centre operator;
• hosting agreement;
• relocation restrictions;
• and what happens if hosting fees are unpaid.

The data centre may have possession of the lender’s collateral without owning it. That creates another layer:

The legal owner and the physical possessor can be different parties.

USD.AI’s published pricing framework distinguishes loans backed by:

• investment-grade or hyperscaler offtake;
• longer-term corporate offtake;
• and on-demand or shorter-term compute demand.

That makes sense. The hardware creates capacity. The customer contract creates expected utilisation. The cash flow services the debt. A simplified model is:

GPU → Compute capacity → Customer / offtake contract → Usage → Revenue → Debt service.

The collateral and repayment source are connected. They are not identical.

This is one of the most interesting features of the asset class. If a borrower defaults, the lender may have security over the GPUs. But before default, repayment comes from operating cash flow. That means underwriting has at least two dimensions.

Asset value

Can the lender recover value from the equipment?

Cash-flow value

Can the operator generate enough compute revenue to service the loan? A loan may have strong equipment collateral and weak cash flow. Or strong contracts and rapidly depreciating equipment. The credit is the combination.

Equipment finance does not always require real-time operational telemetry. GPU finance can. USD.AI describes collateral monitoring that tracks:

• utilisation;
• uptime;
• and asset health.

Its public materials reference on-premises monitoring nodes for this purpose. That creates a new servicing model. The lender can potentially observe:

• Asset exists
• Asset is online
• Asset is being used
• Asset is generating revenue

This is much stronger than relying only on quarterly borrower certificates. But telemetry does not replace legal evidence. It complements it.

A monitoring system may prove that a server is active in Rack 12. It does not prove:

• who legally owns it;
• whether a lien is perfected;
• whether another lender has security;
• whether the equipment was leased;
• whether the data-centre operator has a possessory claim;
• or whether the server can legally be removed.

This is a recurring DaDepo theme:

Evidence of operational activity does not, by itself, establish legal title.

Both matter.

Preserve verification, funding and structural protections

USD.AI’s August recap says the QumulusAI B300 deployment was installed and independently verified before capital was released. The Corvex financing was backed by a delivered and commissioned B200 deployment. That means loan origination can depend on physical asset state. A lifecycle may look like:

Purchase order → Borrower downpayment → Senior financing escrowed → OEM builds → Equipment ships → Installed at data centre → Independent verification → Funds released → Permanent loan active.

This is far more informative than Loan originated: 15 August. The asset itself passes through readiness states.

Equipment finance often contains a circular dependency. The borrower needs financing to buy the equipment. The lender does not want to fund until the collateral exists. USD.AI’s published model addresses this using purchase-order and escrow mechanics. The borrower funds a downpayment. Senior financing is escrowed. The OEM builds and ships the equipment. Once installation and verification are complete, funds are released. This sequence should be visible in the proposed evidence record.

The difference between: Funds committed and Funds released is material.

USD.AI has also announced insurance arrangements around GPU loans. Insurance can potentially protect against specified loss events. But insurance is not the collateral. A GPU financing can therefore include:

Hardware + Security interest + Cash-flow contract + Insurance + Reserve.

Each layer answers a different risk. A good record should distinguish:

• insured asset;
• policyholder;
• beneficiary;
• covered event;
• coverage limit;
• deductible;
• policy period;
• insurer;
• and claim status.

A checkbox called: Insured: Yes is not enough.

USD.AI’s published borrower framework also describes a working-capital reserve equivalent to several months of peak debt service. That buffer is important because compute revenue can fluctuate. The reserve is not collateral value. It is liquidity support. The structure can therefore contain:

GPU collateral → Primary recovery source → Compute revenue → Primary debt-service source → Cash reserve → Temporary liquidity support.

These should remain separate fields.

Track location, serial identity and configuration

A building cannot disappear overnight. GPU servers can be moved. That makes them potentially recoverable and redeployable. It also creates control risk. A lender needs to know:

• can the borrower relocate them;
• must the lender consent;
• is removal physically detectable;
• does the data-centre agreement restrict removal;
• can the secured party access the facility;
• what happens if the operator is insolvent;
• and can the equipment be redeployed to another site?

A collateral record without current location is incomplete.

For highly mobile collateral, identity should ideally survive relocation. The asset may move:

OEM → Warehouse → Data Centre A → Data Centre B → Recovery warehouse → New operator.

The location changes. The asset identity should not. This makes manufacturer, serial, chassis and configuration data important. The same principle applies to:

• aircraft;
• vehicles;
• industrial machinery;
• shipping containers;
• and other movable collateral.

GPU finance is simply a new high-value version of an old secured-lending problem.

Two servers with the same GPU model can have different economic value because of:

• GPU count;
• CPU configuration;
• networking;
• memory;
• storage;
• InfiniBand fabric;
• cooling;
• rack design;
• firmware;
• and cluster architecture.

The financed asset may therefore be: Configured compute system rather than Standalone GPU chip. A collateral schedule should reflect the actual financed object.

Distinguish operating revenue, receivables and technology risk

A GPU cluster can have a contracted offtake agreement. That does not mean all future revenue already exists as a receivable. A useful distinction is:

Contracted compute capacity, usage, accrued revenue, an invoice, a receivable and cash received are distinct states.

Those stages matter. A customer can reserve capacity. Usage may vary. Service credits can reduce invoices. Payments can be late. The lender should not treat the full notional contract value as a current receivable.

USD.AI’s pricing framework explicitly varies with offtake quality. That creates an interesting private-credit structure. The borrower may be a relatively young neocloud. The underlying customer may be:

• hyperscaler;
• large enterprise;
• AI laboratory;
• or another operator.

The loan can therefore be underwritten partly against:

Borrower + Hardware + Customer contract + Customer credit.

This resembles receivables finance layered onto equipment finance.

Traditional secured lending often focuses on physical deterioration. GPU lenders also face technological deterioration. The asset can work perfectly and still lose value. This can happen because:

• new chips outperform it;
• energy efficiency improves;
• customer workloads migrate;
• software support changes;
• memory requirements increase;
• or network architecture changes.

The proposed evidence record should therefore support:

• generation;
• release date;
• current market relevance;
• benchmark data;
• power efficiency;
• and expected replacement cycle.

These are not legal fields. They can still be relevant credit evidence.

Suppose a lender originates: 36-month loan. Six months later, a new GPU generation materially changes resale expectations. The legal loan remains unchanged. The collateral value changes. That should produce a lifecycle event: Valuation update not New asset. Again, the asset identity remains. The state changes.

Review enforcement and investor exposure as separate layers

The lender’s recovery strategy may not be to sell the servers immediately. It might:

• appoint a replacement operator;
• transfer the GPUs to another data centre;
• lease them to a new customer;
• continue generating compute revenue;
• or sell the cluster.

This makes operational control part of recovery. A secured lender may need more than legal title. It may need:

• physical access;
• technical expertise;
• data-centre cooperation;
• transport;
• reinstallation;
• and a customer network.

Recovery value is therefore connected to operational capability.

USD.AI’s model adds a digital layer above the borrower loans. Bullish has said it intends to onboard sUSDai across trading pairs with dedicated market-making support. USD.AI says this could improve secondary liquidity and price discovery for GPU-backed credit. This creates a chain such as:

GPU hardware → SPV → GPU-backed loan → Portfolio → On-chain yield-bearing instrument → Secondary market holder.

The investor at the top does not own the physical GPU directly. The legal and economic chain needs to remain visible.

A liquid token can represent exposure to illiquid collateral. It does not change the physical recovery mechanics. If the underlying loan defaults, the market still needs to understand:

• which GPUs are collateral;
• where they are;
• who controls them;
• what they are worth;
• whether they can be removed;
• and what proceeds reach the investor vehicle.

This is the same private-market principle seen elsewhere:

A liquid representation does not make the underlying asset liquid.

Operating evidence

Telemetry, utilisation and commissioning records can describe the equipment's activity and productive state. They do not by themselves establish ownership, title or lien priority.

Financing and enforcement evidence

Requires the identified equipment, owner or SPV, security documents, relevant contracts and recovery route. Purchase price and current activity do not establish enforcement value.

A proposed evidence model for GPU-backed credit

GPU finance is a useful case for a proposed DaDepo evidence model because the credit cannot be understood from one document.

Record layer	Information to retain
Hardware identity	manufacturer; model; serial number; server chassis; GPU count; configuration; purchase order; invoice; delivery date; commissioning date; current condition.
Ownership	legal owner; SPV; beneficial owner; title evidence; purchase evidence; competing claims; current holder.
Location	data centre; jurisdiction; rack; hosting provider; access rights; relocation restrictions; last verified date.
Security	secured lender; first-lien status; collateral schedule; filing or perfection evidence; SPV security; account security; enforcement rights.
Operations	online status; utilisation; uptime; telemetry source; asset health; power use; maintenance status.
Revenue	offtake customer; contract; term; committed capacity; pricing; utilisation basis; invoicing; receivable; current balance; payment history.
Loan	principal; LTV; interest rate; tenor; amortisation; origination date; maturity; reserve; payment status; current outstanding balance.
Insurance	insurer; policy; coverage; beneficiary; insured assets; exclusions; limit; expiry; claim history.
Digital representation	protocol; investor instrument; token identifier; portfolio link; price; redemption mechanics; market venue; settlement state.
Provenance	OEM record; invoice; verifier; data-centre record; telemetry; UCC or other security record; insurer; borrower; servicer; on-chain transaction; reviewer; last updated date.

This creates an asset record that can survive the full credit lifecycle.

AI assistance and DaDepo's bounded contribution

The following AI uses describe proposed assistance within this evidence model. They do not establish that DaDepo currently automates these workflows. Extraction and inconsistency flags would remain suggestions for review, not legal, credit, compliance or valuation decisions.

AI can help reconcile:

• purchase orders;
• serial numbers;
• invoices;
• shipping records;
• data-centre inventories;
• telemetry;
• utilisation;
• loan schedules;
• and valuation reports.

It can flag:

• a server missing from the latest inventory;
• serial numbers appearing in two collateral pools;
• utilisation dropping sharply;
• location changes;
• stale valuations;
• offtake contracts approaching expiry;
• or loans whose amortisation no longer matches current collateral value.

AI should not independently determine:

• legal ownership;
• lien priority;
• perfection;
• enforceability;
• market liquidation value;
• customer creditworthiness;
• future GPU obsolescence;
• or whether a secured lender should extend financing.

Those remain professional decisions.

DaDepo's supported contribution is private intake of supported documents and preparation of a draft for user review. Its Parties and contractual roles evidence table can record the party, specific contract, source-described role, document and clause reference, relevant source-stated date and review status. Suggested rows require the user's review and confirmation. The wider relationship models, automated monitoring, reconciliation and decision workflows discussed here are proposed capabilities, not a description of existing DaDepo functionality.

DaDepo does not need to become a GPU lender. Its opportunity is to make the asset chain understandable. A GPU-backed financing can be represented as:

GPU hardware → Legal owner / SPV → Data-centre location → Security interest → Compute contract → Revenue / receivable → Loan → Portfolio exposure → Digital investor instrument.

Each arrow should have evidence. A proposed DaDepo extension could help preserve:

• physical identity;
• legal ownership;
• collateral state;
• location;
• valuation history;
• operating state;
• contracts;
• receivables;
• loan lifecycle;
• and provenance.

This would support:

• equipment finance;
• private-credit diligence;
• collateral monitoring;
• servicing;
• portfolio reporting;
• secondary trading;
• insurance;
• and enforcement.

The proposed evidence record does not make the GPU valuable. The proposed model would make the lender’s claim on that value understandable.

Creating or reviewing a GPU or equipment-finance Asset Passport does not mean that DaDepo has:

• authenticated hardware;
• verified serial numbers;
• established legal title;
• perfected a security interest;
• established lien priority;
• valued GPU equipment;
• predicted technological obsolescence;
• verified telemetry;
• assessed data-centre reliability;
• verified customer offtake;
• confirmed receivable enforceability;
• provided a loan;
• operated an SPV;
• provided custody;
• issued a token;
• operated a stablecoin;
• guaranteed liquidity;
• insured the collateral;
• recommended an investment;
• or provided legal, engineering, financial, tax, accounting, investment, lending, underwriting, servicing or valuation advice.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, engineering, lending, equipment-finance, insurance, custody, tokenisation, settlement, underwriting, servicing or valuation advice or services unless a specific service is expressly identified and lawfully provided. GPU ownership, security perfection, collateral value, transferability, insurance, enforcement and investor rights depend on the relevant agreements, jurisdiction, physical asset state and transaction structure.

Review questions for GPU-backed financing

Before a lender treats a GPU cluster as collateral, ask:

1. Asset identity: Which exact servers and GPUs are financed?
2. Configuration: What hardware configuration does each financed unit contain?
3. Ownership: Which legal entity owns the equipment?
4. Purchase evidence: Is title supported by OEM, invoice and payment records?
5. Location: Where is each asset physically located now?
6. Possession: Who has physical custody or control?
7. Security: Which lender has security over the equipment?
8. Priority: Are competing liens or leases present?
9. Perfection: What filing or control evidence supports the lender’s position?
10. Verification: Was installation independently verified before funding?
11. Condition: Is the equipment commissioned, online and healthy?
12. Utilisation: How much of the cluster is actually being used?
13. Offtake: Which customer or contract supports expected revenue?
14. Receivables: What revenue has actually become invoiced and collectible?
15. Depreciation: What economic-life assumption supports the loan tenor?
16. Valuation: What is the current orderly and stressed recovery value?
17. Insurance: What risks are covered and who receives proceeds?
18. Mobility: Can the equipment be moved without lender consent?
19. Enforcement: Can the secured party access, remove, redeploy or sell the equipment?
20. Provenance: Can every important field be traced to the OEM, SPV, data centre, verifier, lender, customer, insurer or servicing source?

If the system knows the borrower owes $20 million but cannot identify the exact machines securing the loan, the collateral is not institutionally ready.

Compute needs an identifiable asset chain

GPU finance is interesting because it turns artificial intelligence infrastructure into a familiar financial problem with unfamiliar collateral. The market is beginning to create:

Equipment finance + Private credit + Receivables + Infrastructure finance + Digital settlement.

around the same physical servers. That creates real opportunities. It also creates a new data requirement. The lender needs to know not only: Who is the borrower? but: Which machine? Where is it? Who owns it? Who uses it? What cash flow does it produce? Who has first claim? What happens when it becomes obsolete? Those questions are what transform GPUs from technology equipment into financeable assets.

When the collateral is compute, the market needs an asset record that can keep up with both the hardware and the credit.

Sources

• USD.AI: USD.AI Secures $100M Bullish Facility
• USD.AI: August Recap—$100M Facility and sUSDai ATH
• USD.AI: GPU Financing
• USD.AI: Borrow Against Your GPUs
• USD.AI: Insights—GPU financing, underwriting and risk management