Capital Windows: Gated company-token conversion with Uniswap v4 custom accounting

Private-company liquidity is usually structured. The company, counsel, transfer agent, or platform controls who can participate, when the window opens, which securities can move, what price or pricing method applies, and how much can be sold. That is closer to a tender window, capital call, or controlled closing than to an always-on public pool.

Capital Windows are built around that reality. The pool is the last step after investor eligibility, data-room access, allocation, counsel-reviewed terms, and signed authorization. Ultramar public materials remain informational. The transaction path belongs behind controlled access.

Capital Windows use a registry, a gated router, and a custom-accounting hook. The registry schedules windows, records investor limits, checks oracle freshness, verifies authorizer signatures, and tracks filled capacity. The router pre-settles exact-input payment. The hook validates the window and delivers company-token output only when the authorization is valid.

The control set covers primary conversion, secondary liquidity, outside-window rejection, total-cap rejection, per-investor-cap rejection, stale oracle rejection, unapproved investor rejection, invalid signature rejection, exact-output rejection, and public liquidity modification rejection.

A normal AMM curve is the wrong default for approved private-market conversion. Primary capital calls and secondary windows often use approved terms, not continuous public price discovery. Uniswap v4 custom accounting lets the hook consume the entire exact input and replace the concentrated-liquidity swap with a custom window curve.

In this implementation, the base price comes from the approved window. Optional step increments can change the conversion rate as scheduled tranches fill. The curve is not trying to infer fair value from raw accounting data during a swap. The oracle gates availability and freshness; it does not silently reprice the company.

A primary conversion window models the final step of a capital call or approved issuer round. The investor has already passed eligibility and allocation review. The window defines the payment token, company token, treasury recipient, start and end time, total cap, per-investor cap, minimum ticket, base price, step size, and required oracle freshness.

When the approved investor sends exact-input USDC through the gated router, the hook verifies the signed payload and window state, routes cash to the issuer treasury, and releases company tokens from hook-held inventory. If the window is paused, expired, stale, over capacity, or missing authorization, the swap reverts.

Secondary liquidity uses the same primitive with a different recipient and mode. Instead of routing cash to the issuer treasury, the window can route cash to seller escrow or a settlement recipient while approved buyers receive company tokens from controlled inventory.

That matters because private-company secondaries should often be company-sponsored and event-based. A window can be dual-sided or tender-like without pretending the asset has unrestricted public market liquidity. The hook blocks generic public LP add/remove actions in the custom-accounting pool.

Uniswap v4 hooks see the router as the sender, not the end investor. Capital Windows handle that by requiring `hookData` with a window id, investor address, minimum company-token output, deadline, nonce, and authorizer signature. The registry verifies the signer and marks the authorization as used.

The router is intentionally narrow: exact input only, payment-token-to-company-token only, and tied to approved pool keys. This keeps generic execution from becoming the compliance boundary. The restricted `AssetToken` remains a second layer of defense because only whitelisted infrastructure and investors can send or receive the company token.

The hook reads the local `SolvencyRegistry` through the window registry. Each window can require a fresh issuer proof, a minimum solvency ratio, and a minimum liquidity ratio. If the proof is missing, stale, or below the window threshold, conversion stops.

This is intentionally conservative. Operating data is a risk gate, not an automatic pricing oracle. The company-token price for a window should come from approved round documents, tender terms, or counsel-reviewed secondary mechanics. The oracle tells the system whether the window is allowed to operate.

A production version would need counsel-approved offering paths, transfer-agent process, custody decisions, deployment verification, monitoring, invariant testing, third-party audit, and issuer-specific documents before any real capital moves.

The ambitious claim is narrower and stronger than a generic RWA AMM: Uniswap v4 can be the programmable settlement layer for structured private-market windows. The hook is valuable because it makes the compliant path more deterministic, not because it removes the need for legal, operational, or investor-protection work.