GPU Cluster Financing Data Room: What Lenders Read Before the Term Sheet (2026)

Last updated: July 2026 · Last verified: July 2026

I'm Sean Yu, co-founder of Peony, a data room company. Most of the financing rooms I watch move through diligence are for assets with an operating history — a company with revenue, a building with tenants, a project with a grid offer. A GPU cluster financing is a stranger animal, and if you are the VP Finance at a neocloud with a term-sheet conversation coming, you already know the discomfort: your raw deal file is a pile of hardware invoices, colocation leases, capacity contracts, and a depreciation model, and a private-credit credit committee is about to decide whether that pile reads like an institutional asset or an amateur's spreadsheet. The room is where that decision gets made.

Here is the thesis. In thirty months, GPU-backed debt went from a $2.3bn private-credit experiment to an investment-grade, publicly syndicated asset class. What changed wasn't the chips — it was the evidence discipline: bankruptcy-remote SPVs, named offtake contracts, and diligence files a credit committee could underwrite. Your data room is where a lender decides whether your raise reads like 2023's exotic bet or 2026's ratable asset.

This guide is for the person building that room: a VP Finance, Head of Capital Markets, or CFO at a GPU-cloud operator raising SPV-structured debt — sometimes equity — secured on H100, H200, or Blackwell fleets plus the customer contracts that run on them. Vehicle sizes cluster in the $20M to $500M range; the counterparties are private credit funds, infrastructure and PE funds, family offices, and vendor-financing desks. Often it is a first institutional raise, which is exactly why "how do I not look amateur to a credit committee" is the live fear this post is written to answer.

Quick answer: A GPU cluster financing data room is the sell-side room a neocloud builds to raise SPV-structured debt secured on a GPU fleet and its customer contracts. The collateral reality is the thing to internalize: the chips depreciate on a contested curve, so the contracts carry the credit — lenders underwrite the offtake counterparty far more than the hardware. The core folder set runs roughly ten workstreams: 01 SPV and corporate, 02 GPU fleet, 03 Facility, 04 Offtake and customer contracts, 05 Utilization and telemetry, 06 Security package, 07 Insurance, 08 Financial model, 09 Vendor relationships, 10 Q&A — sequenced so ring-fencing evidence and offtake quality sit at the top. It is read by private credit funds, infrastructure and PE funds, family offices, and vendor desks. For a $20M to $500M SPV raise, a per-admin room like Peony runs $30 to $64 per admin per month with every recipient free, so the bill is bounded by your small deal team, not by document count.

Where this post sits. This is the compute-layer financing room specifically — where the collateral is chips and contracts, not land and a shell. It is deliberately not the horizontal project-finance guide: for the cross-asset-class raise room (grid, planning, land, model), read Data Room for Infrastructure Projects. If you are actually buying or building the facility — powered land, Will-Serve letters, interconnection on an owned site — that is the Data Center Data Room guide, and your compute raise may simply rent colo inside a facility someone else financed. For UK development-stage diligence detail, see UK Data Centre Due Diligence. And because a lender will run a security review of the room itself before they trust it with named contracts, keep the Data Room Security Questionnaire close — you will be answering its residency, hosting, and access questions.

Why did GPU-backed debt go investment-grade — and what does that mean for your raise?

Because a credit committee now has a template, and your file gets compared to it. Thirty months ago there was no such thing as a rated GPU-backed loan; today there is a public precedent ladder, and that changes the question a lender asks from "can this even be underwritten?" to "does this look like the deals that already cleared?" That is a much easier question to pass — if your room is built to answer it.

The ladder is worth knowing by heart, because it is the narrative your raise is measured against. CoreWeave (Nasdaq: CRWV) is the reference borrower, and its debt escalated in public steps:

• $2.3bn debt facility — August 3, 2023, led by Magnetar Capital and Blackstone. The first landmark: private credit underwriting GPUs plus contracted customer revenue.
• ~$7.5bn facility — May 2024, led by funds managed by Blackstone with Magnetar co-leading, described at the time as one of the largest private debt financings of its kind.
• $2.6bn secured facility — closed July 31, 2025, explicitly backed by the OpenAI contract and secured on "substantially all assets of CoreWeave Compute Acquisition Co. VII, LLC," priced at SOFR plus 4%.
• $8.5bn facility — closed March 31, 2026, the first investment-grade-rated GPU-backed financing (Moody's A3, DBRS A (low)), secured on CoreWeave Compute Acquisition Co. VIII, LLC plus an associated customer contract, with the floating tranche priced at SOFR plus 2.25%.
• $3.1bn facility — closed May 18, 2026, the first publicly syndicated HPC-backed delayed-draw term loan, structured to align with GPU deployment schedules and useful life.

Read the pricing progression and you can see the asset class de-risking in real time: from private-credit rates in 2023, to SOFR plus 4% in mid-2025, to an investment-grade SOFR plus 2.25% by early 2026. What tightened the spread was not a better chip; it was a structure rating agencies and public-market lenders learned to trust — ring-fenced entities, named contracts, and disclosure a committee could rate. For your raise, the practical consequence is liberating and demanding at once: the template exists, so you are not inventing the argument, but your file will be held to the shape of the deals that set it. Build the room to look like the precedent, and a lender can slot your raise into a category they already understand.

What is the collateral, really?

The chips are the collateral on paper; the customer contracts are the collateral that actually gets underwritten. This is the single most important thing to understand about a GPU-backed raise, and getting it backwards is how borrowers build the wrong room. A rack of H100s is a real asset, but it is a depreciating one whose secondary value is volatile, so a lender does not lend against the hardware the way a bank lends against a building. They lend against the contracted revenue the hardware produces — and that means they are underwriting your customer's credit, with the chips as the fallback recovery, not the primary thesis.

Start with why the hardware alone is shaky collateral: GPUs depreciate on a genuinely contested curve. Operators and Nvidia point to four-to-six-year depreciable lives — Nvidia has said customers "consistently use four-to-six-year depreciable lives." Skeptics argue the real economic life is closer to two to three years given Nvidia's roughly annual cadence; in November 2025 the short-seller Michael Burry made the loudest version of this case, contending that several hyperscalers are understating depreciation by extending useful lives. There is no single correct number: under GAAP, useful life is a company-specific estimate, and a change to it is treated as a change in accounting estimate under ASC 250 — applied prospectively, not as an error correction. So the honest framing for your model is that the depreciation assumption is a judgment you must defend, not a fact you can assert, which is exactly why residual value on the chips is a weak foundation for a loan.

That is why the contracts carry the credit. The precedent deals make this explicit: CoreWeave's 2025 facility was secured to deliver services under a long-term agreement with a named hyperscaler, and analysts describe the rating agencies as underwriting the hyperscaler customer, not the GPU hardware. A signed, long-term customer contract with a creditworthy counterparty is what turns a depreciating pile of silicon into a bankable revenue stream — and the room's job is to make that contract, its term, its minimum-commitment structure, and the counterparty's credit legible. Where an infrastructure fund reads a grid offer as the crown jewel (the pattern in the infrastructure projects guide), a GPU lender reads the offtake contract as the crown jewel, and everything else in the room is context around it.

The most extreme illustration of contract-as-collateral is Nvidia's own backstop of CoreWeave: under a master services agreement, Nvidia entered an order form disclosed in September 2025 with an initial value of $6.3bn, under which Nvidia is obligated to purchase CoreWeave's residual unsold capacity through April 13, 2032. That is a vendor guaranteeing the demand floor beneath a customer's collateral — the purest possible statement that in this asset class, the contract is the thing being financed. Most raises will not have a vendor backstop, which makes the quality and durability of your own offtake contracts the entire game.

How to structure a data room for GPU cluster / AI compute infrastructure debt

Structure it by workstream, with the ring-fencing evidence and the offtake contracts at the top, because those are the two questions a credit committee opens first. A GPU financing room is not organized like an M&A room (there is no operating history to interrogate) and not quite like the horizontal project-finance room (the collateral is chips and contracts, not land and consents). It has its own spine, and the spine follows the way a lender actually reads: confirm the collateral is legally separated, confirm the revenue is real and creditworthy, then confirm the model ties the two together.

The workstream logic, before the literal folder tree in the next section, breaks into three moves:

• Establish the ring-fence. The lender's first question is "what, legally, am I lending against, and is it separated from the operating business?" The SPV and corporate documents answer it. If the collateral pool is not cleanly ring-fenced, nothing downstream matters.
• Establish the revenue. The offtake and customer contracts, plus a credit analysis of each counterparty, are what carry the credit. This is where a committee spends the most time, and where covenant-quality questions live.
• Establish the reconciliation. The financial model — with its depreciation, refresh, and utilization assumptions — has to be traceable to the contracts and the fleet. A model that assumes a contract term the agreement does not support, or a utilization rate the telemetry contradicts, is the fatal error.

Everything else in the room — the fleet file, the facility file, the security package, insurance, vendor schedules — is evidence supporting one of those three moves. Sequence the index so a reviewer meets them in that order, and the room argues your case without you in the room. For the general discipline that underlies any raise room across asset classes, the infrastructure projects guide covers the shared mechanics; this section is the compute-specific version of it.

How to build / organize a data room index (folder structure) for an SPV / GPU debt raise

Use a numbered ten-folder skeleton so the index is stable as you add documents and a returning reviewer never has to relearn the room. Here is a working top-level structure for a GPU-backed SPV raise — treat it as the standard-practice synthesis it is, assembled from how these facilities are actually secured, not as a single quoted checklist:

1. 01 SPV & corporate — formation and governance of the bankruptcy-remote borrower, the organizational chart showing where the SPV sits relative to the parent, independent-director terms, and (where warranted) a non-consolidation opinion. This is the ring-fencing evidence, and it sits first.
2. 02 GPU fleet file — purchase agreements, invoices, serial numbers, quantities and models (H100 / H200 / GB200), and delivery schedules. This is your proof of title to the specific chips pledged.
3. 03 Facility file — colocation leases plus power capacity and PPA or utility contracts, and interconnection agreements; or, if you own the site, the owned-site file. If your raise involves building rather than renting the facility, the Data Center Data Room guide covers the powered-land and Will-Serve side that a colo tenant simply inherits from the landlord.
4. 04 Offtake & customer contracts — the signed long-term customer agreements, their term and minimum-commitment structure, and a credit analysis of each offtaker. This is the core collateral folder.
5. 05 Utilization & telemetry reporting — periodic or real-time GPU utilization and uptime data, because contract-cover and residual-value assumptions depend on it, and it increasingly becomes a covenant.
6. 06 Security package — first-priority liens on the chips, assignment of the customer contracts and their receivables into the SPV, account control agreements, and intercreditor or waterfall terms.
7. 07 Insurance — property, business-interruption, and, where used, residual-value insurance on the chips.
8. 08 Financial model & assumptions — the model driving amortization, with the depreciation and refresh schedule, the utilization assumptions, and the contract-cover analysis alongside it.
9. 09 Vendor relationships — OEM allocation and delivery schedules, which are frequently a closing or draw condition because the collateral does not exist until the chips are delivered and racked.
10. 10 Q&A — the logged question-and-answer thread that runs through the whole raise, so questions, answers, and any released document live in one auditable place.

The sequencing is deliberate: 01 and 04 answer the two kill questions (is the collateral ring-fenced, is the revenue creditworthy), 08 reconciles them, and the rest is supporting evidence a reviewer reaches for as needed. Numbered folders keep the index legible even as document count climbs into the hundreds.

Staged disclosure for a compute raise: teaser, NDA, and tiered permissions

Stage disclosure in tiers — teaser, then NDA, then graduated room access — so your most sensitive documents open only to counterparties that have earned them, because on a GPU raise your customers are often your funders' competitors. This is the tiered-permissions problem in its sharpest form: the named offtake contract is simultaneously your best evidence and your most dangerous leak, and you are running several funds through the same room in parallel.

The standard funnel:

1. Teaser. A short overview that lets a fund decide whether to engage without exposing customer names, contract pricing, or the SPV specifics. Anyone invited can see it.
2. NDA gate. Access to the room proper is conditional on accepting an NDA — the click-through record that a counterparty agreed before they saw a single confidential document.
3. Room tiers. Inside the room, folder-level permissions per counterparty class decide who sees what, and the named contracts stay staged behind a later unlock even for approved groups.

The competitors-as-counterparties problem is what makes the mechanics load-bearing. You may be showing your offtake book to three private-credit funds who also lend to your customers, or whose portfolio companies compete with them. So the question of who sees customer names versus redacted offtakes is not cosmetic — a lender can and should assess contract term, minimum-commitment structure, and counterparty credit off a redacted summary long before they need the logo, and you release the unredacted, fully named agreement only to a counterparty close enough to a term sheet to need it. The mechanics that make this routine:

• Visitor groups. Each counterparty class is its own group with its own folder map, so "who can see the named contracts" is a group setting, not a per-file scramble, and no fund ever sees a competing fund's presence.
• Dynamic watermarks. The named contracts and the model carry each viewer's identity burned into the page, so a leaked copy points back to the counterparty it came from — a real deterrent when you are circulating your most sensitive terms.
• Page-level analytics. You see which fund opened the offtake contracts and how long they spent, which is your clearest read on who is genuinely progressing toward a term sheet versus who is just browsing.

How to set up tiered / granular permissions for different lenders (vs advisors) in a VDR

Give each class of reader its own visitor group and attach only the folders that class needs to underwrite its question. A GPU raise typically has three distinct reader types who should never share a view: the lenders themselves, their technical advisors, and vendors or delivery counterparties. They read different things:

• Lenders live in the offtake contracts, the security package, and the model's coverage — they are underwriting the credit and the recovery path.
• Technical advisors (the specialist consultants a credit committee hires) live in the fleet file, the utilization telemetry, and the facility and power documents — they are validating that the chips exist, run, and stay powered.
• Vendors need only a narrow, scoped folder relevant to their piece — often just the delivery-schedule slice tied to their allocation.

So the lender group sees folders 04, 06, and 08; the technical-advisor group sees 02, 05, and 03; the vendor group sees a single scoped folder; and none of them sees another group's correspondence or the other counterparties' identities. Because recipients are free on a per-admin plan, isolating three funds, their advisors, and two vendors into separate views costs nothing extra — the same reason the best data rooms for private equity increasingly run per-admin rather than per-seat. This is the granular-permission discipline a credit committee reads as a run process, and it is the difference between a controlled raise and a leaked contract.

The compute-debt structure: how these facilities are actually built

These facilities are built as borrowing-base SPVs — a bankruptcy-remote entity holds a defined pool of GPUs and the associated customer contracts, and the loan is secured on that pool and sized against it. Understanding the structure tells you what the room has to prove, so here is the anatomy, drawn from the public precedent deals.

The ring-fenced borrowing base is the foundation. Each landmark CoreWeave facility is secured on a dedicated single-purpose entity — the publicly disclosed "CoreWeave Compute Acquisition Co. VII, LLC" and "...Co. VIII, LLC" borrowers — into which the chips and the contracts are ring-fenced so lenders have a bounded collateral pool and a clean recovery path if the operating parent fails. Your room's SPV folder exists to show a committee that same separation at your scale: which chips and which contracts sit inside the entity, that it is not commingled with operating cash, and that the security package attaches to assets the SPV actually owns.

The facilities are also structured to self-amortize against the customer contract term and the hardware's useful life — the precedent loans mature in step with the contracts they finance, and the first public syndication was explicitly structured to align with GPU deployment schedules and useful life. That is the reconciliation your model has to demonstrate: principal and interest repaid over a horizon the contracts and the depreciation schedule both support.

On advance rates — the percentage of appraised fleet value a lender will actually lend against — the honest answer is that the specifics are deal-by-deal and not reliably public. Advance rates are set by the quality of the offtake and the covenant, the useful-life assumption, and the residual-value view, which is precisely what the room evidences; a stronger contract and a more defensible depreciation case support a higher advance. Rather than quote a number, the useful posture for your raise is to make the inputs that drive the advance rate legible — contract durability, counterparty credit, utilization, and a depreciation schedule that survives a pessimistic case — and let the lender size it. (This is also why the recurring "what advance rate can I get on an H100 fleet" question is really a covenant-quality question wearing a pricing costume: the advance follows the evidence, not the other way around.)

The first questions a lender asks, in the order they tend to arrive: Is the SPV genuinely bankruptcy-remote and are the assets inside it? Who are the offtakers and how creditworthy are they? What is the utilization and how is it reported? What useful life and residual value does the model assume, and does the loan survive a shorter one? When do the chips actually arrive? Build the room so each of those has an obvious folder to answer it, and the diligence moves fast. For the market-level view of how private credit prices these, the virtual data room cost guide covers the room economics; the deal economics sit in the model.

Credit committee questioning chip delivery schedule risk in diligence

When a committee questions delivery-schedule risk, they are pointing at a real structural fact: the collateral does not exist until the chips are delivered and racked, so the delivery schedule is frequently a closing or draw condition, not a footnote. This is distinct from the depreciation debate — it is not about how long the chips last, but about whether they arrive at all, on the timeline the model assumes. A GPU-backed facility funded before the fleet is delivered is lending against a promise of hardware, so lenders tie draws to delivery milestones and read the vendor schedule hard.

Two risks live in this folder. The first is plain delivery risk: OEM allocation timelines slip, and a draw conditioned on delivery slips with them. The room answers it with the vendor relationships and delivery-schedule documents (folder 09), showing allocation, confirmed order forms, and realistic racking timelines a lender can tie a draw condition to.

The second is generation-reset risk, and it is the one that unsettles committees most. Nvidia's roughly annual product cadence — Hopper (2022), then Blackwell (2024), then Rubin (2026), with Rubin Ultra reported to follow — means the generation you are financing today can be superseded while your loan is still outstanding. A committee worries that a fleet ordered against one generation loses secondary value and competitive utilization when the next ships; Jensen Huang's own quip that when Blackwell shipped in volume "you couldn't give Hoppers away" is exactly the line a skeptical lender has in mind. The room does not make that risk vanish, but it addresses it: show the generation you are buying, the refresh plan in the model, and — critically — that the offtake contracts are structured so the customer is committed across the loan term regardless of what ships next. Delivery-schedule discipline plus contract durability is what converts "the chips might be obsolete before you repay us" from a deal-killer into a modeled, mitigated risk. And because a lender will separately probe how securely the fleet is powered — colo capacity, PPA, interconnection — keep the facility file (folder 03) tight; power security is the delivery risk's twin, and the data centers solution page covers the digital-infrastructure side of it.

Datasite vs Intralinks for infrastructure / private credit due diligence — and where a per-admin room fits

For a $1bn-plus syndicated GPU raise, Datasite and Intralinks are the incumbent default, and honestly so — they are the enterprise VDRs a bank's procurement expects, with deal-team-scale tooling and AI suites built for large syndicated processes. On a mega-facility with an arranging bank, that is the procurement reality, and I will not pretend a per-admin room displaces it at that altitude. Between the two, both are enterprise-grade; the choice usually comes down to which one the arranging bank already runs and which post-download control model the deal requires — the practical distinction most desks weigh is Intralinks's persistent post-download rights management versus Datasite's redaction-and-AI breadth. Either way, on the $1bn syndicated deal, the enterprise VDR is where you land.

The lane where a per-admin room fits is the one this post is written for: the $20M to $500M SPV raise run by a small neocloud deal team, without a bank's procurement behind it. There, the enterprise per-page and per-project meters run heavier than a one-off, document-heavy, self-run raise warrants, and the security stack has converged enough that a modern per-admin room carries the controls a credit committee needs. Using only site pricing canon, the split is concrete:

• Datasite — around $68K on annual enterprise deals; the default on $1bn-plus syndicated raises.
• iDeals — roughly $500 to $1,000 per month depending on scope; a strong mid-market option with 24/7 support.
• Peony — $30 per admin per month (Business), $52 (Data Room), or $64 (Deal Team), all annual, with every recipient free.

The deciding factor is rarely the feature list — it is whether the pricing model matches the shape of your deal. A GPU raise is document-heavy by nature (hardware invoices, technical reports, a large model, a growing contract set), which is exactly where per-page pricing punishes you and a flat per-admin model does not. For the full market comparison across providers, the top 10 virtual data room providers teardown and the cost guide go axis by axis. The honest rule: enterprise VDRs for the syndicated mega-facility, a per-admin room for the SPV-lane raise where the meter, not the brand, is the deciding factor.

The honest risk section: what serious sponsors put in the room rather than hoping nobody asks

The sponsors who close fastest put the risk file inside the room, because a credit committee that finds a risk you disclosed reads it as candor, and one that finds a risk you hid reads it as a reason to walk. On a GPU raise, three risks are large enough that a serious lender will raise them whether or not you do — so address them in the room, on your terms.

Offtaker concentration. These structures live or die on the creditworthiness and stickiness of a few customers, and concentration in a single offtaker is the risk a committee flags first. The precedent case is instructive: CoreWeave's reported reliance on a single hyperscaler for a large share of 2024 revenue is exactly the concentration lenders scrutinize. Your room should show the concentration honestly — what share of the facility's contracted revenue each offtaker represents — alongside whatever mitigants you have: contract term and minimum commitments, counterparty credit quality, and any diversification in the pipeline. Hiding concentration does not make it smaller; disclosing it lets you frame the mitigation.

Generation resets. As above, Nvidia's annual cadence (Hopper to Blackwell to Rubin) means the fleet you finance can be superseded mid-loan, and the depreciation debate — the four-to-six-year operator assumption versus the two-to-three-year Burry critique, framed as a company-specific estimate under ASC 250 — is the modeled-assumption risk a committee probes hardest. Put the depreciation schedule, the refresh plan, and the sensitivity cases in the model folder, and show the loan amortizes even on the pessimistic life. This is the single biggest modeled assumption in the file; treat it as something to evidence, not to bury.

The circularity discourse. There is a live 2025–2026 debate — mapped in detail by Bloomberg in its coverage of "AI circular deals" — about vendor-financing loops in this sector: Nvidia invests in and backstops neoclouds and AI labs, those parties spend on Nvidia chips and Nvidia-powered capacity, and value loops back to Nvidia, with the $6.3bn CoreWeave capacity backstop the most-cited example and comparisons drawn to Lucent's late-1990s telecom vendor financing. A serious lender knows this discourse, so if your structure touches any of these loops — a strategic investor who is also a vendor, a backstop, a warrant — name it in the room and explain why your contracted revenue is real end-demand rather than circular. The steel-man matters too: operators argue this is normal infrastructure financing for a genuine capacity shortage, and a committee will weigh both sides. Put the facts in the room and let the strength of your actual contracts answer the skepticism.

The common thread: the risk file is not a confession, it is a control. A room that pre-answers the three questions every GPU lender asks is a room that reads as run by people who have thought about the downside — which is precisely the credibility a first-time institutional borrower needs to project. Peony's 5,900+ customers run controlled disclosure on exactly this logic: show the hard documents, gate them properly, and let the discipline signal the seriousness.

How Peony fits

I run Peony, a data room company, and I will be plain about where it fits and where it does not. Peony gives a neocloud deal team the specific controls a credit committee's process needs, without a bank-scale procurement:

• NDA gating so a counterparty signs before they see a single named contract.
• Granular folder, file, and page permissions plus visitor groups so lenders, technical advisors, and vendors each get an isolated view and competing funds never see each other.
• Dynamic watermarks that burn each viewer's identity into the named contracts and the model, so a leak is traceable.
• Page-level analytics as investor-intent radar — which fund opened the offtake contracts, and for how long — so you time your term-sheet push from engagement data, not from who is politest on a call. (To be precise: this is view-and-dwell analytics, not keystroke capture.)
• AI Q&A that runs against the models you connect, with zero retention — you bring the model, your documents are not retained, and answers draw from what is in the room, which is the right posture for confidential deal documents.
• Instant revocation and exportable audit logs, so access ends when a party drops out and you have the record a committee's process expects.

On the claims that matter to a diligence-minded reader: Peony is SOC 2 Type II. Standard plans process in the US (AWS us-east-1) under SCCs with a DPA; custom data residency (including UK and EU), BYOK, and self-hosted deployment are available on the Enterprise plan — which is the answer to the residency line on the security questionnaire a lender will send. The UK is Peony's second-largest market, with 140+ customers across the UK and Europe. The platform has held 99.96% uptime since August 2025, with a 4-minute-19-second median setup time, so a small team can stand up an institutional-looking room the afternoon it decides to raise. And the pricing is the structural fit for the SPV lane: $30 to $64 per admin per month with every recipient free on the pricing page, which is why 5,900+ customers run controlled sharing without the bill scaling with the audience.

What Peony does not do is make your raise bankable — that is your SPV structure, your offtake contracts, and your model. Consider the anonymized archetype this post is built around: a US GPU-cloud operator financing 30MW Tier 3/4 sites through SPVs, whose entire pitch is that the ring-fencing, the customer contracts, and the depreciation model hold together. Peony makes the room that proves that case look like it was run by a team three times the size — which, on a first institutional raise against chips and contracts, is exactly the leverage the room exists to give.

Frequently asked questions

We're raising a $100M GPU-backed facility — what documents should go in the data room?

Lead with the two things a credit committee actually underwrites: the ring-fenced entity and the contracts that carry the credit. A working set is ten folders — 01 SPV and corporate (formation and governance of the bankruptcy-remote borrower, org chart, non-consolidation opinion), 02 GPU fleet (purchase agreements, invoices, serial numbers, quantities and models, delivery schedules), 03 Facility (colo leases or owned-site file, power capacity and PPA or utility contracts, interconnection), 04 Offtake and customer contracts plus a credit analysis of each counterparty, 05 Utilization and telemetry reporting, 06 Security package (first-priority liens on the chips, assignment of contracts and receivables, account control agreements), 07 Insurance, 08 Financial model with depreciation and refresh assumptions, 09 Vendor relationships and delivery schedules, and 10 Q&A. The order is the argument. A lender does not read front to back; they go to the SPV to confirm the collateral is ring-fenced, then to the offtake contracts to confirm the revenue is real, then to the model to confirm the two reconcile. The chips are the asset on paper; the contracts are the asset that actually gets underwritten. Structure the index so those answers are the first ones found, and the raise reads as institutional rather than as a folder of hardware invoices.

We're raising SPV debt on our H100 fleet — do we need a real VDR, or is Google Drive fine for lenders?

For an institutional debt raise you need a real room, and the reason is control, not polish. A shared drive has no NDA gate, no per-viewer watermark, no folder-level permissions per counterparty, and no page-level analytics — so you cannot stop two competing private-credit funds from seeing each other, you cannot trace a leaked offtake contract back to the counterparty who leaked it, and you cannot tell whether the fund actually opened the model or just the teaser. A credit committee reading a Google Drive link also reads a signal: this borrower has not run a financing before. On a GPU-backed facility your most sensitive documents — named customer contracts, pricing, the depreciation model — are exactly the ones you most need to gate, stage, and watermark, and a shared drive does none of that. A dedicated room does all of it, and on a per-admin plan the cost is a rounding error against a facility measured in tens or hundreds of millions. Google Drive is fine for internal drafting; it is the wrong tool for lender diligence on an asset-backed raise.

For a GPU-backed SPV raise, is iDeals or Datasite the better data room?

It depends entirely on the size of the raise, and both are genuinely strong incumbents. Datasite is the enterprise default — deal-team-scale tooling, an AI suite, and the brand a bank's procurement expects on a large syndicated facility — priced accordingly; site pricing canon puts Datasite around $68K on annual enterprise deals. iDeals sits in the mid-market at roughly $500 to $1,000 per month depending on scope, with strong 24/7 support and a cleaner setup. The honest split: if you are running a $1bn-plus syndicated raise with a bank arranging it, the enterprise VDR is the reality and part of what you are paying for. If you are a neocloud standing up a $20M to $500M SPV facility with a small deal team, both of those meters can run heavier than the deal warrants, and a per-admin room where recipients are free usually fits the shape better. The deciding factor is rarely the feature list — modern rooms have converged on the security stack — it is whether the pricing model matches a lean, one-off, document-heavy raise or a bank-scale syndication. Match the tool to the altitude of the deal.

We're standing up the lender room — how do we structure it and redact customer names in the offtake contracts before sharing?

Structure it by workstream with the SPV and the offtake contracts at the top, and redact customer identities at the document level until a counterparty has cleared the NDA and, often, a later disclosure stage. The reason redaction matters so much on a GPU raise is that your customers are frequently the competitors — or the customers — of the funds reading your room, so a named offtake contract is the single most sensitive document you hold. The practical sequence: build the numbered folder skeleton, gate the room behind a click-through NDA, and inside the room keep the offtake folder staged so the teaser and a redacted contract summary open first, with the fully named agreements released only to a counterparty that is genuinely progressing. Redact at the document level — customer name, pricing, any identifying volume detail — so a lender can assess contract term, minimum-commitment structure, and counterparty credit quality without yet seeing exactly who the customer is. Then, when a fund is close enough to a term sheet to need the name, you release the unredacted version to that specific visitor group, watermarked to each viewer. Control the identity, not the substance: the lender can underwrite the covenant long before they need the logo.

Lenders keep hammering our offtake covenant quality — what do they actually want to see in the data room?

They want evidence that the contracted revenue is durable, enforceable, and creditworthy enough to repay the loan on its own — because on a GPU-backed facility the contracts, not the chips, are the real collateral. Concretely, a credit committee reads the offtake folder for four things. First, term and structure: how long the contract runs, whether it carries a minimum commitment or take-or-pay-style floor, and how the revenue amortizes against the loan. Second, counterparty credit: a genuine credit assessment of each offtaker, because the lender is effectively underwriting your customer's ability to pay, not your enthusiasm. Third, enforceability: termination rights, assignment provisions, and what happens to the contract if you default — since the security package assigns those receivables to the SPV. Fourth, concentration: how much of the facility's revenue depends on a single offtaker, which is the risk that most worries a committee. Put a clean contract summary at the top of the folder, the credit analysis beside it, and the full agreements behind appropriate staging. When lenders keep hammering covenant quality, it is almost always because the room shows them the contract exists but not why the counterparty is good for it; close that gap and the questions stop.

How do we prove our GPU useful life is 5-6 years, not 3, to a skeptical credit committee?

You cannot prove a single number, so the honest move is to evidence your assumption, disclose the debate, and show the loan survives the pessimistic case. Operators and Nvidia point to four-to-six-year depreciable lives; skeptics — most prominently Michael Burry in late 2025 — argue real economic life is closer to two to three years given Nvidia's roughly annual product cadence. A credit committee knows this argument cold, so a model that quietly assumes six years and hopes nobody notices reads as naive. What works instead: state your useful-life and residual-value assumptions explicitly, tie them to your actual refresh and utilization plan, and note that useful life is a company-specific estimate under GAAP treated as a change in accounting estimate under ASC 250 if it moves. Then run the model at a shorter life and a lower residual and show the facility still amortizes within the customer contract term — because a loan structured to repay over the contract, not over the hardware's optimistic tail, is far more defensible. Put a depreciation and refresh schedule in the model folder, and put the sensitivity cases beside it. You are not winning the depreciation argument; you are showing the credit does not depend on winning it.

How much does a virtual data room cost for a GPU financing / SPV debt raise, and is flat-fee or per-page cheaper?

For a $20M to $500M SPV raise, a per-admin flat plan costs in the low hundreds of dollars total and is almost always cheaper than per-page or per-user pricing, because a GPU raise is exactly the document-heavy, large-file case that runs a per-page meter up. Peony is priced per admin seat: Business is $30 per admin per month, the Data Room plan is $52 per admin per month (adding dynamic watermarking and unlimited rooms), and the Deal Team plan is $64 per admin per month (adding advanced redaction and an advanced Q&A module), all on annual billing, with every recipient — every fund, advisor, and vendor you invite — free. A raise running with two to four admins over a few months lands in the low hundreds of dollars regardless of how many hardware invoices, contracts, and technical reports you load. Compare that with enterprise VDRs quoted per page, per GB, or per project, which land in the $15K to $68K range: Datasite around $68K on annual enterprise deals, iDeals roughly $500 to $1,000 a month. Those are built and priced for large syndicated deals. So flat-fee or per-page? For a document-heavy compute raise, per-page is the model that punishes you and per-admin flat pricing is the one that does not — the bill is bounded by your small deal team, not by document count or counterparty list.

We're a 40-person neocloud — how do we make our deal file look institutional to a private-credit credit committee?

Institutional is a function of discipline, not headcount, and on a GPU raise it comes down to five things a committee reads as evidence of a run process. First, a numbered folder skeleton that mirrors the diligence workstreams — SPV, fleet, facility, offtake, security, model — so a reviewer lands and knows exactly where the collateral and the contracts are. Second, a single current financial model behind a stable link, with its depreciation and utilization assumptions beside it, so nobody underwrites last month's numbers. Third, watermarked sensitive documents — the named contracts and the model carry each viewer's identity. Fourth, folder-level permissions per counterparty class, so competing funds never see each other and customer names stay staged. Fifth, a logged Q&A thread instead of a scatter of emails. A 40-person shop that does those five things presents a file a credit committee takes as seriously as one from a firm ten times its size; a larger team that dumps invoices and contracts into a flat drive does not. The room is the first work product a lender sees, and on a first institutional raise it carries a disproportionate share of the credibility your track record has not yet earned. Discipline is the signal, and it is entirely within your control.

How do we prove SPV ring-fencing and bankruptcy remoteness to lenders in the data room?

You prove it with the entity documents that show the collateral pool is legally separated from the operating business and cannot be dragged into its bankruptcy. In the room, that means an 01 SPV and corporate folder holding the formation documents of the bankruptcy-remote borrower, its governance terms (including any independent-director requirement), the organizational chart showing where the SPV sits relative to the parent, and, where the structure warrants, a non-consolidation opinion. The precedent structures make the pattern concrete: the landmark GPU facilities are secured on dedicated single-purpose entities — publicly disclosed borrowers such as CoreWeave Compute Acquisition Co. VII and VIII, LLC — into which a defined pool of GPUs and the associated customer contracts are ring-fenced so lenders have a bounded collateral pool and a clean recovery path. Your room should show the same logic at your scale: which chips and which contracts sit inside the SPV, that the entity is separate and not commingled with operating cash, and that the security package attaches to assets the SPV actually owns. A credit committee is checking that if the parent fails, the collateral they lent against is still there and still reachable. Make that legibility the job of the SPV folder, and put it first.

How do we give lenders, their technical advisors, and vendors different access — and track who viewed the offtake contracts?

You run one room with a visitor group per counterparty class and attach only the folders each group needs, then use page-level analytics to see exactly who opened what. Lenders, their technical advisors, and vendors are underwriting different questions: the lender wants the offtake contracts, the security package, and the model's coverage; the technical advisor wants the fleet file, utilization telemetry, and the facility and power documents; a vendor or delivery counterparty needs only the narrow slice relevant to them. So the lender group sees the contract, security, and model folders; the technical-advisor group sees the fleet, telemetry, and facility folders; the vendor group sees a single scoped folder; and no group sees another group's correspondence or the other counterparties' identities. Sensitive items — the fully named offtake contracts, the full model — can stay staged behind a later unlock even inside an approved group. Because recipients are free on a per-admin plan, you can give three funds, their advisors, and two vendors their own isolated views without the bill moving. Then page-level analytics close the loop: you see which fund actually opened the offtake contracts and how long they spent, which tells you who is real and where the diligence questions are coming from before the call. One room, many sightlines, full visibility into each.

Related resources

• Data Room for Infrastructure Projects — the horizontal project-finance raise room across asset classes
• Data Center Data Room — the facility acquisition: powered land, Will-Serve letters, and energization risk
• UK Data Centre Due Diligence — UK development-diligence detail: NESO grid queue, NSIP/DCO, planning
• Data Room Security Questionnaire — how to answer the residency, hosting, and access questions a lender sends
• Virtual Data Room Cost Guide — how VDR pricing models compare across the market
• Best Data Rooms for Private Equity — the per-admin versus enterprise split for fund deal teams