An IPv4 lease needs authority, evidence, and a clean return path.

This is a pre-launch design and legal-review draft for a possible IPv4 exchange coordinated by RENANT LIMITED. The current website may demonstrate buyer and supplier workflows, but it does not establish that a prefix has been verified, listed, reserved, routed, monitored, or leased.

An operational service would require adopted agreements, identity and authority verification, an approved upstream announcement path, document storage and signing, payment and tax decisions, monitoring sources, incident procedures, and provider acceptance.

Resource holder

The party shown by appropriate registry and contractual evidence to hold or control the address resource.

Supplier or lessor

The party offering a time-limited right to use the prefix. It may be the holder or an authorized intermediary.

Lessee

The verified organization receiving the limited right to use the prefix for an approved purpose and period.

Announcing network

The provider or network authorized to originate or propagate the route, which may require its own review and LOA format.

Renant

The intended coordination, evidence, workflow, and support layer. Renant is not automatically the resource holder or route origin.

Upstream parties

Regional registry, routing, hosting, reputation, payment, signing, or monitoring providers involved in the completed arrangement.

The accepted lease must identify the actual parties and their responsibilities. A role label in a website application is not proof of authority.

Before a listing can become eligible, the intended controls should require:

• Verified legal-entity and authorized-representative details for the supplier.
• Canonical prefix, prefix length, applicable registry, registration status, and relevant account or maintainer references.
• Evidence that the supplier holds the resource or has a current, transferable right to lease and authorize routing.
• Review of current and recent origin ASNs, route objects, ROAs/RPKI status, more-specific announcements, reverse DNS, geolocation, and material reputation history.
• Confirmation that registry, provider, financer, prior lessee, or other contract restrictions do not prohibit the proposed use.
• An accurate operational and abuse contact able to act during the proposed term.

Verification is time-sensitive. A change in holder, contract, registry record, routing state, authority, dispute, or sanction may require re-verification or removal from the catalog.

A prospective lessee should provide verified organization and authorized-user details, intended workload, expected traffic pattern, countries involved, announcing network or hosting need, requested prefix and term, abuse contact, and any prior relevant address or service history.

Approval should consider lawful purpose, provider compatibility, technical readiness, payment and fraud risk, abuse risk, sanctions and export obligations where applicable, and the ability to respond to incidents. An application or successful identity check does not guarantee approval.

Higher-risk uses may require additional controls or may be unavailable from the relevant supplier or network. Renant should not route a customer to a provider whose agreement forbids the disclosed use.

A public or private listing should show only verified, authorized, and current information appropriate for disclosure. Planning examples must remain visibly separate from eligible prefixes.

A lease forms only under the effective terms and an accepted lease schedule identifying the prefix, parties, use, term, price and currency, announcement model, documents, and offboarding obligations.

A draft LOA should be produced from verified records and carry a unique document number and template version. It should identify:

• The exact prefix and permitted more-specifics, if any.
• The resource holder or authorized lessor and its authorized signer.
• The lessee, announcing network, and authorized origin ASN or other precise routing purpose.
• The effective date, expiry date, revocation method, and relationship to the lease.
• Required provider, registry, and operational contacts.

Issued versions should be protected from alteration, retained with a content hash and signature evidence, and shared only with authorized parties. A change to prefix, ASN, party, purpose, or term requires a new approved version rather than an informal edit.

Expiration, termination, loss of authority, or a valid revocation should make the LOA unusable for new or continued routing. A relying network may require its own checks and is not required to accept a Renant-generated format.

The lease schedule should identify who creates and removes route objects, ROAs or other routing authorizations, BGP announcements, reverse DNS delegations, geolocation corrections, and provider assignments. Each change must stay within verified authority.

RPKI can help a resource holder express which origin AS is authorized, but a valid ROA does not by itself form a lease, prove beneficial ownership, guarantee reachability, or remove the need for provider approval. Incorrect ROAs or route objects can disrupt service.

RENANT LIMITED should not promise global reachability, geolocation, acceptance by every network, clean reputation, or a specific convergence time. Routing remains dependent on authorized upstream networks and the wider Internet.

The lessee may use an assigned prefix only for the organization, services, locations, networks, and term approved in the lease. Subleasing, reassignment, transfer, a new announcing ASN, or a material use change requires prior approval.

The draft Acceptable Use Policy applies. In particular, the prefix must not support spam, phishing, malware, botnets, unauthorized access, denial-of-service attacks, source spoofing, route hijacking, deceptive identity, sanctions evasion, or rapid reputation evasion.

The supplier should disclose known material reputation or routing problems. The lessee is responsible for new activity during its term and for timely containment. Neither party should manipulate monitoring evidence or shift known abuse to an adjacent prefix.

If implemented and disclosed, monitoring may collect time-stamped observations from routing tables, origin and more-specific changes, RPKI validation, registry records, reverse DNS, public or licensed reputation sources, upstream provider events, and customer-authorized network telemetry.

Monitoring should use the minimum information reasonably needed. Packet contents should not be inspected by default. Any deeper inspection requires a documented legal and contractual basis, necessity, proportionality, access controls, retention period, and appropriate notice or exception.

Signals can be incomplete, delayed, licensed, or wrong. One blocklist or automated score should not alone trigger an irreversible decision. Material alerts should be deduplicated, preserved with source and timestamp, assessed in context, and routed for appropriate review.

A report should identify the prefix or address, precise timestamps and timezone, observed behavior, supporting logs or headers, affected system, and a safe reply route. Unnecessary secrets and personal data should be removed.

Depending on severity, the intended response may include notice, evidence request, credential rotation, service isolation, port restriction, null route, announcement withdrawal, provider escalation, temporary suspension, or lease termination. Active attacks, hijacks, serious unlawful harm, or binding provider or legal demands may require immediate action.

Where safe and permitted, the lessee should receive the reason, evidence summary, required remediation, deadline, and review route. Suppliers and lessees must cooperate with reasonable investigation and preserve relevant evidence lawfully.

1. Confirm the lease-end time and stop new assignments before it.
2. Move customer services and remove reverse DNS or application dependencies.
3. Withdraw route announcements and remove or revise route objects, ROAs, provider assignments, and LOAs.
4. Confirm that the lessee and its downstream users have stopped using and advertising the prefix.
5. Record final routing and reputation observations and unresolved incidents.
6. Apply a risk-based cooling or remediation period before a returned prefix is offered again.

Return does not guarantee immediate removal from third-party reputation or geolocation databases. Responsibility for post-term remediation, fees, and cooperation must be allocated in the lease schedule.

A lease schedule should state price, currency, billing interval, deposit or reserve treatment, upstream and routing charges, taxes, late or failed payment consequences, early termination, provider costs, and any reputation-remediation responsibility. A display currency is not automatically an accepted settlement currency.

Ownership, authority, route, abuse, or payment disputes may require pausing a listing or assignment while evidence is reviewed. Final terms must define escalation, governing law, forum, remedies, and liability after professional review; this draft does not invent them.

Identity, authority, document, routing, monitoring, and abuse records should be handled under the adopted Privacy Notice with role-based access and justified retention.

RENANT LIMITED
3906, 39/F, THE CENTER, 99
QUEEN'S ROAD, CENTRAL
HONG KONG