EXECUTION ARCHITECTURE
How an exit actually executes
A take-profit protocol lives or dies on one question: can a manipulated price, a hostile caller, or a dead component take the gain? Below is the full answer. Every mechanism described is enforced in verified contract code — not in policy.
1 · The oracle: guarded, or it doesn't count
Targets trigger against a GuardedOracle with two hard gates. Staleness: a price older than the freshness window is not a price — reads revert rather than serve it. Deviation: a single update may not move the feed more than 20% — a manipulated print on a thin pair cannot teleport the oracle to a fake level in one step; an attacker would need to sustain the manipulation across multiple updates, paying real market cost the whole way.
2 · The keeper: permissionless, and safe to be
Anyone may call seal() on a vault whose target the oracle confirms — the caller earns a tip of 0.1% of the realised gain, paid from the owner's share, so execution never depends on our server being alive. This is safe for one reason: the engine derives its own slippage floor from the oracle price, and a caller's parameters can only make execution stricter, never looser. The floor is 3% below the oracle price by default; the owner can widen it per asset for thin pools, up to a hard ceiling of 20% ($MOONX is set to 15%), and each vault keeps the floor it was minted under — a later change never touches an open vault. A hostile keeper cannot sandwich the sale below that floor; the transaction reverts instead. Refusing to sell is the designed failure mode — a bad fill is permanent, a delay is not.
3 · Slippage: who bears it
Execution costs (DEX fees, price impact within the vault's floor) come out of gross proceeds before the 80/20 split — the owner and the protocol share costs in the same ratio as gains. The protocol never tops up a fill and never socialises one vault's slippage onto others. If the book cannot absorb the position within the floor, the sale reverts and the vault stays open.
4 · Circuit breakers and the dead-protocol case
- Stale oracle → trading halts. No component ever prices against a feed nobody is maintaining. Early termination still works, but with no fresh price progress counts as zero, so it costs the full 30%.
- Oracle dead 30 days → unconditional rescue. The holder withdraws the full position, penalty-free, via
rescueWithdraw()— the Rescue withdraw button on /vaults appears on a vault once the engine says it would succeed. The hatch reads a non-reverting timestamp — it can never be blocked by the failure it exists to escape. - No pause on exits. There is no code path — for the team or anyone — that can freeze a withdrawal or termination.
- No admin withdrawal function. Every function that moves a vault's asset pays the vault's owner, and there is no sweep, rescue-to-owner or emergency-withdraw for deposits.
- One power that matters, until launch. Until the engine's wiring is finalised, its owner can re-point it at a different price feed and swap router, and that applies to open vaults — which is how an operator could force a bad sale. Finalising is a one-way switch planned for launch; after it, neither can be changed. Operator keys are single hot wallets, not multisigs.
5 · MEV posture
The oracle-anchored floor is the primary defence: value extractable by ordering games is capped at the vault's floor, and the keeper tip makes honest execution the profitable strategy. Sales go to PulseX directly through a fixed adapter, one pool path per asset, set by the owner. There is no batch or intent venue and no per-fill impact cap on the deployed engine; those exist only in a draft for a later version.
6 · Size and liquidity, honestly
There is no maximum vault size in the contract. What limits a clean exit is pool depth. Measured on 9 September 2026, the largest vault that sealed in a single transaction within its floor was about $10,000 in WPLS, $2,500 in HEX and $500 in $MOONX. Above that, a whole-vault seal reverts, and the keeper sells in slices — half, a quarter, an eighth, a sixteenth — as the pool allows, re-trying on later runs. A large vault in a thin token can take many attempts to close, and if even a sixteenth cannot fill, it waits. The operator is alerted when a vault at its target stays unsealed.
7 · What you are paid in
Proceeds, dividends and fees settle in USDC on PulseChain — USDC bridged from Ethereum by the PulseChain Bridge, worth a dollar only while the bridge holds the USDC behind it. The settlement token is fixed in the contracts. We monitor the bridge's backing every 15 minutes; the risk disclaimer explains what that does and does not protect against.
Current deployment is PulseChain mainnet, all contracts verified. Not externally audited — see the Risk disclaimer. Risk disclaimer · Transparency
