Summary
- BTW's directory records a US company, PF IPV4 Borrower, LLC, whose name describes a position in a financing transaction rather than a network role; the entry lists two supporting public references, no confirmed operator, no primary domain and no prior BTW coverage.
- ARIN's Number Resource Policy Manual carries a section titled "Specified Transfer Recipient Requirements" whose surviving text measures operational use — 50 percent of requested addresses used within 24 months — against the party receiving addresses, while the registry's published transfer file names transferees and dates and says nothing about lenders, liens or consideration.
The gap between those two sentences is the whole article.
The name describes a position, not a network
Infrastructure companies usually name what they do. They route, they host, they connect, they lease, they transit. A name that says borrower names the other side of the transaction: not the function performed on the network but the function performed on a balance sheet. Whoever incorporated that vehicle chose a word that describes a liability, and they chose it deliberately enough to put it in the legal name.
That is a legitimate corporate form. Special purpose vehicles exist for exactly this: hold one asset, isolate one risk, give one counterparty a clean claim on a defined pool of value, keep the operating business at arm's length from the financing. Nothing about that structure is improper, and nothing in the record reviewed here shows that this particular vehicle holds, routes, has ever held, or has ever sought a single IPv4 address. BTW's directory entry for PF IPV4 Borrower, LLC Only for Strategic Circle records a US company with two supporting public references, no confirmed operator and no primary domain — a filing footprint, not an operational one.
So treat the name as a hypothesis generator, not a finding. What makes it worth an article is not the company. It is that the name points at a question the address market has not answered publicly: when an address block is pledged, what exactly has the lender received, and what happens on the day it wants it back?
What the registry measures
ARIN's Number Resource Policy Manual contains a section whose title is unusually direct: "8.5. Specified Transfer Recipient Requirements." The subsections listed under it are "8.5.1. Registration Services Agreement," "8.5.2 Operational Use," "8.5.3. Minimum Transfer Size," "8.5.4. Initial Block" and "8.5.5. Block Size." The retained text of that page carries two standards verbatim: "50 percent of the requested IPv4 addresses will be used within 24 months," and "Demonstrates 50 percent of the sum of all previous IPv4 allocations is efficiently used." Both are quoted from the manual's page at arin.net.
Read the grammar of those two sentences. The subject is use. The object is the recipient. Nothing in either standard asks who paid, who lent, who holds a security interest, or who bears the loss if the entity that received the block stops being the entity that benefits from it. The test is a test of operational absorption: do you actually need this, and are you actually consuming what you already have.
Two limits on that reading have to be stated in the same breath. First, the manual reached this article as a provider-reported excerpt of the ARIN page, not as a page opened and read line by line; the effective date and the completeness of that text are unverified. Second, the surviving excerpt does not carry the operative wording of 8.5.3, the minimum transfer size. A /24 figure has circulated in summaries of ARIN policy. It is not in the retained text, it is not asserted here, and anyone who needs the number should read the manual rather than this article.
Even bounded that way, the structural point holds. The requirements are recipient requirements. That is what the section says it is.
The register names the recipient, not the financier
The second document is the registry's own transfer data, published as a machine-readable file at ftp.arin.net. It is not an aggregate count. It is a per-transferee register: a transfers array whose records carry the recipient organisation's name, its country code, a transfer date and a transfer type.
The sample record retained for this article is Cisco Systems, Inc., country code US, ASN range 3943–3943, transfer date 2012-08-06T17:46:00Z, type RESOURCE_TRANSFER. It is a single record and it is truncated with explicit ellipses, so it establishes the shape of the register and nothing more — not whether any particular organisation appears in it, and not whether any particular organisation is missing from it.
The shape is what matters. The unit of publication is the transferee, named and dated. The register says: this party was recognised on this date for this type of transfer. It does not say what the block cost. It does not say what the block secured. It does not say whether the recipient's balance sheet treated the block as an operating asset or as collateral behind a note.
That is not a criticism of ARIN. A registry's job is to keep an accurate record of who holds number resources and to apply the policy community's transfer rules. Financing disclosure is a securities and secured-transactions function, and it lives in different registries entirely. But the consequence for anyone reading the public record is blunt: registry visibility is not financing transparency. You can see the recipient. You cannot see the encumbrance.
A summary of ARIN's separate transfer-policy page, retrievable at arin.net/resources/registry/transfers/policy, describes the regime as generally requiring a recipient to demonstrate technical need for the resources requested. That page arrived here as a summary without a retained excerpt, so it is cited as a description of the regime's stated posture and not as operative text.
Two layers, one exit
Put the two documents together and a two-layer structure appears.
The first layer is private credit. A loan, a security agreement, a collateral schedule, a priority position, a default clause, a realisation mechanism — all of it governed by whatever law the parties chose, all of it documented between them, almost none of it visible to a third party. If an address block sits inside that layer as collateral, its treatment is a contract question.
The second layer is registry recognition. A transfer of number resources between organisations is an event the registry must recognise, and recognition has conditions attached. The conditions, per the manual's own framing, are recipient-facing.
Now follow a default through both layers. A lender holding a pledge over a block wants value out of it. There are routes that do not require the block to move: take the proceeds of a sale, take equity in the vehicle that holds the block, appoint a receiver over the entity, sell the company rather than the addresses. Each of those keeps the registry record exactly where it is and moves something else instead — cash, shares, control.
And then there is the route where the block itself has to leave. That route ends at a recipient. If the acquirer is a fund, a financing arm, a receiver or a vehicle assembled for the disposal, it arrives at the registry as a party that must satisfy the requirements the manual sets out — a Registration Services Agreement, a showing of operational use, a utilisation standard measured against what it already holds.
Whether ARIN's process would treat a foreclosure or a secured-party transfer differently from a commercial sale is a question this article cannot answer. Nothing in the material reviewed describes a foreclosure procedure, an involuntary-transfer mechanism, or a secured party's standing. That absence is reported as an absence. It is the single most important open question in the piece, and it is open.
Where the discount comes from
An address block is priced off comparables: recent transactions, block size, RIR region, whether the prefix is clean, whether it carries routing history. That is a market valuation of an asset that changes hands. It is a reasonable way to value a block you intend to sell to an operator.
It is an incomplete way to value a block you intend to seize.
If realisation requires the block to pass through a recipient review, then the realisable value is not the market price. It is the market price to the subset of buyers who can satisfy the review, adjusted for the time the review takes and the probability it does not go the way the lender assumed. That adjustment does not have to be large. It has to be priced. And it is invisible in a term sheet that treats the block as a liquid asset with a quoted price.
This is the part of the collateral story that no register will ever show. A pledge over an address block is a claim on an asset whose exit is gated by an institution that is not a party to the loan, is not obliged to consider the lender's interest, and applies criteria written for network operators. The asset is financeable. The seizure is conditional. Those two statements are compatible, and only one of them appears in the collateral schedule.
The absence, stated once
What the reviewed record does not contain matters, and it has to be stated with the right force — no more and no less.
A company-name search of the SEC's EDGAR filing system for "IPV4 Borrower" returned no matching filer at retrieval time (the search). That result exists here as a provider-written summary with no retained excerpt, and its scope is exactly one name search in one filing system. It does not establish that this company has no debt, no lender, no secured borrowing, or no financing recorded under a different name, a different spelling, an affiliate, or a state-level filing regime.
No loan agreement, security agreement, collateral schedule, financing statement, pledge, lender identity or default notice for this entity appears in the material reviewed. That is a statement about the material reviewed. It is not a statement about the company.
The logic runs one way only. The records examined do not establish that financing exists. Their silence does not establish that it does not. Doctrine's phrasing is the right one and it belongs in the article rather than in a footnote: ARIN's stated transfer process tests recipient need and utilisation; the records reviewed identify transferees but do not identify a lender or security interest; any financing arrangement therefore remains unverified — not disproved.
Why the name still earns its place
Return to the name. "Borrower" in a legal name is not a confession and not a disclosure. It is a description of the vehicle's purpose, written by the people who created it, for the benefit of whoever needed to know what the entity was for — a lender, a tax adviser, a filing clerk, a counterparty doing diligence.
What it tells a reader of the public record is that vehicles of this shape exist in the address market, are named for what they do, and are legible as financing structures to anyone who reads names for a living. What it does not tell a reader is whether this one borrowed, from whom, against what, on what terms, or with what registry consequence. Those are the questions a lender's diligence file answers and the public record does not.
That is the structural finding, and it does not depend on this company at all. Every party valuing an address block as collateral faces the same seam between a private contract and a public recognition layer. The register will show the transfer. It will not show the pledge. The policy will test the recipient. It will not test the lender. And the lender, having priced the block off comparables, will discover at the worst possible moment that the exit is a qualification review rather than a settlement.
That is worth knowing before the loan is signed, not after.
Sources
- ARIN Number Resource Policy Manual, section 8.5 "Specified Transfer Recipient Requirements" — arin.net/participate/policy/nrpm
- ARIN published transfer register data — ftp.arin.net transfers_latest.json
- ARIN transfer policy page (provider summary only) — arin.net/resources/registry/transfers/policy
- SEC EDGAR company-name search for "IPV4 Borrower" (provider summary only) — sec.gov EDGAR search
- BTW directory record — PF IPV4 Borrower, LLC Only for Strategic Circle
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





