Do not assess an IPv4 broker or transfer facilitator only by available inventory, price, or promised speed. Due diligence should verify the intermediary’s role, the source’s authority, the recipient’s eligibility, the applicable RIR process, closing controls, address history, operational readiness, and post-transfer responsibilities.
The broker question is really several different questions
An intermediary may help find a counterparty, organize documents, coordinate with a Regional Internet Registry (RIR), or support closing. Those services can be valuable, but they do not replace the registry’s decision, legal review, technical validation, or the recipient’s operating responsibilities.
Lu Heng’s note on why the broker question is also a registry-risk question provides the useful editorial distinction behind this checklist: the visible transaction is only one layer. Buyers and recipients also need to understand the registry interface and what happens after the deal closes.
Use current policy and transaction evidence to test that perspective. The applicable process depends on the source, recipient, resources, RIRs, transfer type, and legal entities involved.
Define each party’s role before evaluating claims
Terms such as broker, marketplace, facilitator, advisor, and platform are not interchangeable. Start by documenting the actual scope.
| Party | Possible role | What not to assume |
|---|---|---|
| Source | Makes resources available and supplies authority and registration evidence | That the source is eligible to transfer every listed resource |
| Recipient | Establishes eligibility, funds the transaction, accepts records, and prepares operational use | That payment alone creates registry recognition or routing readiness |
| Broker or marketplace | Introduces counterparties and may support negotiation | That a listing proves authority, clean history, eligibility, or completion |
| Transfer facilitator | May organize evidence and coordinate the RIR workflow | That facilitator status guarantees approval or transaction performance |
| RIR | Applies its current policy and updates registration records when requirements are met | That RIR processing replaces commercial, legal, security, or operational diligence |
| Legal counsel and closing provider | Advises on agreements, authority, conditions, escrow, and closing evidence | That they have verified routing, reputation, or network usability unless expressly engaged to do so |
| Network and security teams | Validate routing, RPKI, IRR, DNS, abuse history, monitoring, and deployment readiness | That registry completion automatically makes the resources production-ready |
For example, ARIN operates a Qualified Facilitator Program. ARIN says participation is optional and that qualified facilitators undergo its review process. That is relevant evidence for ARIN-region work, but it is not a substitute for transaction-specific diligence or a rule that can be generalized to every RIR.
Identify the exact registry path
Before requesting a quote, record:
- the current RIR and registration record for the resources;
- the source and recipient legal entities;
- whether the transaction is intra-RIR or inter-RIR;
- the requested prefix size and exact ranges;
- whether the resources are current, legacy, historical, reserved, subject to a holding period, or otherwise specially classified;
- the expected transfer type, such as a specified-recipient transfer or a transfer related to a merger, acquisition, or reorganization;
- which party submits each request and pays each fee; and
- which current policy pages and forms govern the transaction.
Do not rely on a generic statement that a block is “transferable.” Eligibility can depend on facts that are not visible in a sales listing.
ARIN’s transfer quick guide describes different transfer paths, authority requirements, recipient qualification, source restrictions, and ongoing record-maintenance duties. APNIC likewise states that its transfer process follows APNIC policy, requires supporting information, and updates the APNIC Whois Database after processing.
For RIPE NCC resources, begin with the current resource-management and transfer pages and follow the specific request and policy links for the resource type. Rules and forms can change, so save the version or access date used for the transaction plan.
Verify source authority and chain of records
A credible intermediary should be able to explain how authority will be established without asking the recipient to accept unsupported assurances.
Request evidence appropriate to the transaction, which may include:
- the current registry organization and authorized contacts;
- the source’s legal name and registration details;
- evidence linking any previous name, merger, acquisition, reorganization, or dissolved entity to the current source;
- authority for the individual giving instructions;
- a list of the exact prefixes included and excluded;
- disclosure of leases, assignments, liens, disputes, restrictions, or third-party use where applicable;
- confirmation of the registry path needed to correct stale records before transfer; and
- a documented process for resolving a mismatch between the contracting party and the current registry record.
The recipient should not collect unnecessary personal or confidential data. Agree on secure exchange, access limits, retention, redaction, and deletion before documents move between parties.
If the chain is unclear, make registry confirmation or corrective work a condition before funds become irrevocable.
Check the intermediary’s operating model
Ask the broker or facilitator to answer these questions in writing:
- Are you acting for the source, the recipient, both parties, or only as an introducer?
- How are fees calculated, and who pays them?
- Do you receive a spread, commission, referral fee, or other compensation?
- Which diligence tasks are included, excluded, or performed by third parties?
- Who communicates with each RIR, and who remains responsible for the accuracy of submissions?
- What evidence shows experience with this specific RIR and transfer type?
- What happens if the registry requests more information or rejects the request?
- What event releases funds?
- What evidence marks registry completion?
- What post-transfer support is included, for how long, and under what response times?
- How are conflicts of interest disclosed and managed?
- How are sensitive corporate and registry documents protected?
A fast answer is less important than a precise one. Vague scope creates gaps between the contract, registry workflow, and technical cutover.
Make closing depend on objective evidence
The commercial closing sequence should align with the registry process. A useful control matrix identifies:
| Stage | Required evidence | Decision owner |
|---|---|---|
| Candidate block accepted | Exact prefixes, current registration, preliminary technical and reputation review | Recipient |
| Source cleared | Authority and chain-of-record evidence reviewed | Legal/transaction owner |
| Recipient cleared | Current RIR eligibility or pre-approval evidence where available and appropriate | Recipient/RIR |
| Submission accepted | Correct requests and supporting documents submitted by authorized parties | Source and recipient |
| Registry completed | Current registry evidence shows the intended recipient or organizational outcome | Transaction owner |
| Operational acceptance | Routing, RPKI, IRR, reverse DNS, monitoring, security, and abuse contacts work as designed | Network/security owners |
| Funds released | Contractual closing conditions are satisfied | Authorized closing party |
| Transaction closed | Records, access, fees, renewals, support ownership, and evidence retention are assigned | Business owner |
This table is a starting point, not legal advice. Counsel and the RIR should confirm the appropriate conditions for the actual transaction.
Do not use a broker email, invoice, routing announcement, or database screenshot as a universal substitute for registry completion. Define the accepted evidence for the relevant RIR before signing.
Treat post-transfer operability as a separate gate
Registry completion does not answer every operational question. Before production use, verify:
- the intended origin AS and routing policy;
- route object creation or updates where used;
- RPKI access and any Route Origin Authorizations needed for the intended origin;
- reverse DNS delegation and change authority;
- abuse and operational contact accuracy;
- geolocation and reputation data that may affect intended services;
- current route visibility and unexpected origin history;
- security-tool, partner, and customer allowlist dependencies;
- monitoring coverage and alert ownership;
- account access, multifactor authentication, recovery, and personnel continuity;
- renewal, maintenance, membership, sponsorship, or contractual duties that apply; and
- the runbook for future changes, incidents, and another transfer.
An address block may be correctly registered but still require technical and third-party updates before it is suitable for a particular workload. Test each intended use rather than accepting a general claim that the space is “clean” or “ready.”
Reputation is also time- and service-dependent. A block that passes one data source today is not guaranteed to remain accepted by every provider. Record the tools, dates, findings, exceptions, and remediation owner instead of relying on a permanent cleanliness guarantee.
Look for evidence, not reassuring language
Pause the transaction when you encounter:
- pressure to pay before the source, prefixes, or registry path are identified;
- a contracting entity that does not match the registry record and has no documented chain;
- guarantees of RIR approval, routing acceptance, clean reputation, or universal geolocation;
- refusal to state whom the intermediary represents or how it is paid;
- policy claims without links to current RIR documentation;
- an unexplained request to route the block before registry completion;
- a closing trigger based only on the intermediary’s confirmation;
- no plan for registry questions, rejection, delay, or return of funds;
- no owner for RPKI, IRR, reverse DNS, abuse contacts, or registry-account access;
- a promise that every post-transfer task is “handled” without a named deliverable;
- sensitive documents exchanged through uncontrolled channels; or
- a proposal to use a different transaction form merely to avoid a stated policy requirement.
A red flag does not always prove misconduct. It does mean the responsible owner should stop, obtain evidence, and decide whether the gap can be corrected.
Require a post-transfer handover package
Before closure, assign and collect:
- final registry evidence;
- the executed agreement and closing record;
- a prefix schedule;
- submitted and approved RIR materials appropriate for retention;
- current organization and contact records;
- registry-account ownership and recovery responsibilities;
- RPKI, IRR, reverse DNS, routing, and abuse-contact status;
- reputation and geolocation baseline results with dates;
- open exceptions and remediation owners;
- recurring fees, agreement dates, and review reminders;
- intermediary support terms and escalation contacts; and
- an evidence-retention and secure-deletion record.
The package should let a future operator understand what was transferred, how it was recognized, how it became operational, and who maintains it without depending on one employee or intermediary.
Evaluate the complete transfer, not only the introduction
A good intermediary assessment connects commercial scope, registry execution, closing evidence, technical acceptance, and lifecycle ownership. It makes gaps visible before payment or deployment and prevents an introduction service from being mistaken for an end-to-end guarantee.
Use the NRS.Help explanation of why IP address transfers require RIR approval as a starting point, then replace general assumptions with the current policy pages, evidence requirements, and operating controls for the actual transaction.
