Hi everyone,
As Monad pushes toward near CEX-level throughput and latency, perpetual protocols on the chain are increasingly expected to support fast, reactive risk controls such as leverage caps, close-only modes, and emergency halts.
These controls already exist in most perp designs today, but they tend to be:
- implemented differently across protocols
- managed off-chain or via privileged scripts
- opaque to routers, frontends, and automation
- difficult to reason about or compose across systems
I wanted to start a discussion around whether it makes sense for perpetual protocols on Monad to optionally expose a minimal, on-chain risk policy interface.
The goal is not to dictate how risk is calculated internally, but simply to standardise how risk state is surfaced on-chain.
Problem statement -
Across existing perpetual designs, on Monad and elsewhere:
-
risk controls like close-only mode, leverage limits, or trading halts are protocol-specific
-
frontends and routers must hard-code logic for each protocol
-
emergency states are difficult to verify or automate against
-
there is no machine-readable way to ask: “what risk mode is this market currently in?”
As throughput increases, these inconsistencies become more painful, especially for:
-
smart routers and aggregators
-
automated agents
-
governance tooling
-
monitoring and alerting systems
Proposed direction -
One possible direction is to define a minimal interface that a perpetual protocol can implement to expose its current risk policy on-chain.
At a high level, this interface could expose signals such as:
-
whether new positions are currently allowed
-
whether the system is in close-only mode
-
leverage or size constraints
-
emergency or kill-switch state
Some guiding principles for such an interface:
-
Minimal: small surface area and easy to implement
-
Composable: readable by UIs, routers, and agents
-
Non-opinionated: does not prescribe how risk is modeled
-
Optional: protocols opt in, no forced enforcement
What this is not
-
not a replacement for off-chain risk engines
-
not a mandate on how risk must be computed
-
not a liquidation or oracle system
-
not tied to any single perpetual design
The focus is strictly on standardising visibility, not control.
Open questions for discussion
I’d appreciate feedback from builders and the Monad team on:
-
Is this a real pain point for perpetual builders on Monad today?
-
Which risk signals would be essential versus optional?
-
Should this live as a standard interface, or as a shared reference contract?
-
Would this materially help routers, UIs, or automation on Monad?
-
Are there Monad-specific considerations (throughput, block time, governance patterns) that should influence the design?
If there’s interest, I’m happy to follow up with a concrete draft interface and a reference implementation for discussion.
Looking forward to thoughts.
Summary
TL;DR:
Perp protocols already use risk controls like leverage caps and close-only modes, but they’re implemented inconsistently and often managed off-chain. This post explores whether a minimal, optional on-chain interface for exposing risk state could improve composability, automation, and tooling across Monad perps.