RWAs on the engine

The current property unit uses MintwareOwnedPoolMarketEngine on Base Sepolia. The deployment record includes activation, seed contribution and liquidity deployment. It replaces the retired standalone property demo.

Underlying tokens outside; virtual tokens inside #

The pool’s currencies are the verified PermissionsAdapter and USDC. This Uniswap wrapper holds the restricted underlying property token and creates a 1:1 virtual currency that only PoolManager holds. When PoolManager takes an output, the wrapper burns the virtual units and delivers the underlying token to the recipient. See Uniswap’s Permissioned Pools overview for the underlying standard.

Pool currencies are sorted by their addresses. The engine replaces the adapter currency with its underlying token in that same slot, without sorting again. Appraisals, NAV, deposits and payouts preserve this correspondence. Always read the engine’s token order.

Three permission checks, not one allowlist #

Only the bound engine may add or remove liquidity through this hook. Adds check wrapper trust and the engine’s liquidity flag. Removals and fee collection do not check current allowlist permission, wrapper approval, trading pause, swap enablement or appraisal freshness. Underlying transfers must still succeed.

Owned-pool shares cannot transfer between nonzero addresses: both transfer and transferFrom hit SharesNonTransferable. This prevents passing an existing pooled claim around the eligibility checks enforced on mint. It does not add forced seizure or recovery. Burns remain possible for exits.

The appraisal is also the engine’s mark #

MintwareRwaAppraisalHook implements IMarketAssetMark. A publication includes an appraisal tick, the time the underlying observation was made, and a report hash. Zero or future observation times, non-increasing observation times and an empty report hash are rejected. The report hash is emitted in ObservationRecorded; the contract does not verify the appraisal’s real-world truth.

The first appraisal may be initialized by the owner or keeper. Later postAppraisal(int24 tick, uint64 observation, bytes32 reportHash) calls are keeper-only. Three constraints limit updates:

• maxStepTicks bounds each absolute tick change.
• minUpdateInterval spaces publications using their on-chain publication time.
• maxDriftTicksPerDay caps the sum of absolute movements in the rolling 24 hours. Reversals count too; each movement expires separately.

Freshness uses the observation time, not publication time. Read config() for the actual band, fee, cadence, drift, age and grace parameters. The configuration fields are policy limits for this hook; they are not a promised valuation range for the asset.

Trading band and the gap-closing exception #

Before a swap, the hook requires a bound engine, enabled adapter swap switch, approved wrapper and permitted trader, an unpaused hook, and a fresh appraisal. It selects coreFeePips or specFeePips from the pre-swap distance to the appraisal tick.

This exception lets trades reduce a gap after an appraisal moves. It does not permit arbitrary trading outside the outer band. The hook’s appraisal band is distinct from the engine’s LP range; the engine independently applies its pool-versus-mark guard when deploying or recentering.

Keeper rotation and configuration #

Replacing the keeper requires owner proposal and confirmation after 48 hours. Configuration can change immediately before pool initialization; after the pool is bound, changes use a 48-hour proposal/confirmation delay. Appraisal maximum age and exit grace are frozen once the pool key is pinned. The owner can replace the guardian immediately.

The hook owner or guardian can call pauseTrading(); only the owner calls resumeTrading(). This is independent of the engine’s pause. The adapter owner separately controls the checker, trusted wrappers and swap switch. Those adapter controls do not inherit the hook’s timelock.

Stale appraisal: trading halts, exits get a grace window #

Permission revocation does not by itself gate pool removal or collection. However, issuer freezes, blocked recipients, unreadable adapter NAV or failed fee collection can still prevent a withdrawal. A recenter that cannot re-add liquidity reverts atomically, restoring the original position.

What is not enabled yet #

The committed deployment record says swaps are disabled: the adapter swap switch is off and no router is allowed. Trading needs a permissioned router approved in allowedWrappers, its trader principal allowed to swap, the switch enabled, and all hook and native transfer checks satisfied. The owned engine’s optional idle-swap path is deliberately disabled.

The asset and allowlist are test-only fixtures with open setters, not production issuer controls. The app’s RWA unit and public read endpoint expose current reads separately from these recorded deployment facts.

See all current deployments, including the issuer fixtures and idle adapters.