EXITSHIELDMARKET RESEARCH
TECHNOLOGY / V9.1

Eight mechanisms.
One bounded system.

EXITSHIELD combines per-wallet eligibility, a shared batch, and finite liquidity. Each mechanism has a specific scope—and specific limits. Nothing here is deployed on-chain.

Designed around a dedicated market.

The batch allocator, shared budget, order expiry, and base reserve cannot be guaranteed by a standard token transfer hook alone. They need a market that controls and settles the orders.

Architecture notes
01
MECHANISM 01 / 08

Anti-Whale Holding Cap

Bounded concentration

Research specification

What it does

A configurable holding limit can cap the tokens counted to a registered wallet or authority in the EXITSHIELD market.

WHY IT EXISTS

Concentration can make one large holder's behavior dominate a small market. A visible limit explores how distribution constraints change that risk.

ILLUSTRATIVE EXAMPLE

If the hypothetical supply were 1,000,000 tokens, a 1% cap would equal 10,000 tokens per counted wallet.

WHAT IT DOES NOT GUARANTEE

A wallet is not a person. Multiple keys can split holdings, and a strict aggregate cap needs complete account registration or token-level transfer controls. Neither is implemented on-chain.

TECHNICAL REQUIREMENTS

Compatible token and registered accounts for transfer-level enforcement; a dedicated market for market-side checks.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
02
MECHANISM 02 / 08

Accumulative Sell Allowance

Earned selling capacity

Research specification

What it does

A wallet's eligible balance can accumulate a capped allowance over time. The allowance makes an order eligible to be submitted; it does not reserve liquidity or guarantee a sale.

WHY IT EXISTS

A cap that replenishes over time may spread potential sell requests across windows instead of letting the full balance enter at once.

ILLUSTRATIVE EXAMPLE

At a hypothetical 2.5% recharge rate, 1,000 eligible tokens accrue up to 25 credits in a window, before applying the credit cap.

WHAT IT DOES NOT GUARANTEE

Rate, cap, transfer treatment, and registration rules remain experimental. Credits cannot identify one person behind several keys.

TECHNICAL REQUIREMENTS

Dedicated market for escrow, reservation, and settlement; compatible token controls may be needed for strict transfer rules.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
03
MECHANISM 03 / 08

Global Exit Budget

One shared limit

Research specification

What it does

A market-wide token budget constrains how much can be sold in a window, subject to the SOL reserve and execution constraints.

WHY IT EXISTS

Individual limits alone can add up to more than the market can settle. A shared budget makes the total capacity explicit.

ILLUSTRATIVE EXAMPLE

If 20 holders are each eligible for 500 tokens, a 2,000-token window budget keeps total allocation within 2,000.

WHAT IT DOES NOT GUARANTEE

A token budget is not a promised SOL payout. Reserve, price impact, floor, and order limits can reduce execution further.

TECHNICAL REQUIREMENTS

Dedicated market with shared state and atomic or committed batch allocation.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
04
MECHANISM 04 / 08

Demand-Adaptive Liquidity Engine

Funded demand signal

Research specification

What it does

Net SOL actually contributed by eligible purchases can inform a capped candidate budget for a later exit window.

WHY IT EXISTS

A market may want its exit capacity to reflect capital actually added, rather than just counting trades or activity.

ILLUSTRATIVE EXAMPLE

If 10 SOL of eligible net inflows are recorded, a hypothetical 20% candidate ratio would be 2 SOL before other limits.

WHAT IT DOES NOT GUARANTEE

Wash trading, coordinated entities, and external pools remain concerns. The rule is experimental and cannot create liquidity.

TECHNICAL REQUIREMENTS

Dedicated market that can account for funded net inflows once and settle against its own reserve.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
05
MECHANISM 05 / 08

Fair Batch Auction

Allocation without queue priority

Research specification

What it does

Eligible orders are collected until a cutoff, then allocated proportionally under one shared capacity calculation.

WHY IT EXISTS

In a congested market, sequential fills can privilege timing. A batch tests whether shared allocation can reduce that race.

ILLUSTRATIVE EXAMPLE

If two equal orders share a 100-token capacity, each receives 50 in the illustrative allocation, regardless of arrival order.

WHAT IT DOES NOT GUARANTEE

This is not a guaranteed uniform price or fill. Compute limits, rounding, price limits, and congestion need implementation and testing.

TECHNICAL REQUIREMENTS

Dedicated market required; a transfer hook alone cannot collect and allocate a batch.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
06
MECHANISM 06 / 08

Manual One-Window Exit

Every order is deliberate

Research specification

What it does

A sell request applies to one window. Any unfilled admissible amount expires instead of silently rolling forward.

WHY IT EXISTS

An automatic standing request can act later when the holder is no longer watching. A one-window order makes resubmission explicit.

ILLUSTRATIVE EXAMPLE

A holder whose 100-token order fills for 40 must sign a new request to try selling the remaining 60 later.

WHAT IT DOES NOT GUARANTEE

A user may authorize software to submit later orders. Expiry does not guarantee a fill or a faster exit.

TECHNICAL REQUIREMENTS

Dedicated market order lifecycle and an explicit user signature for each new request.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
07
MECHANISM 07 / 08

Exit Transparency Dashboard

Show the full path

Product concept

What it does

A public dashboard is intended to distinguish requested, eligible, filled, and expired amounts alongside reserve and settlement data.

WHY IT EXISTS

A single 'sold' number can hide denied requests or exhausted capacity. Showing each stage helps holders understand what happened.

ILLUSTRATIVE EXAMPLE

A partial fill should show the original request, amount admitted, tokens sold, SOL paid, and the expired remainder.

WHAT IT DOES NOT GUARANTEE

An indexer can lag or be unavailable. Wallet addresses do not identify people, and displayed spot price differs from realized execution.

TECHNICAL REQUIREMENTS

Market events/state plus an off-chain indexer; verifiable sources and indexing slots should be shown.

CURRENT DEVELOPMENT STATUS

Product concept. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
08
MECHANISM 08 / 08

Base Liquidity Engine

A finite funded reserve

Research specification

What it does

A dedicated constant-product pool can settle eligible exits against SOL already in its reserve.

WHY IT EXISTS

A reserve may allow some settlements without a same-window buyer, while making the actual source and limit of payment visible.

ILLUSTRATIVE EXAMPLE

A seller might receive SOL even with no same-window buyer, but only while the funded pool has permitted capacity.

WHAT IT DOES NOT GUARANTEE

The pool can be depleted. Reserve floors, impact limits, and market conditions can stop or reduce a sale; no price floor is promised.

TECHNICAL REQUIREMENTS

Dedicated market and an actually funded, program-controlled liquidity vault.

CURRENT DEVELOPMENT STATUS

Research specification. No production implementation or audited contract.

RESEARCH SCOPE ONLY · EXAMPLES ARE NOT TARGET SETTINGSBack to top ↑
DEX compatibility is not automatic.

Axiom, FOMO, Pump.fun, and other external markets have not been validated with EXITSHIELD. A market needs explicit integration and testing to enforce the dedicated-market rules.