CONTROLS AND PERMISSIONS
| Control layer | Typical authority |
|---|---|
| Public venue surface | Market reads and other non-sensitive venue views |
| Authenticated gateway routes | Account state, fills, funding history, and signed trading flow |
| Restricted service routes | Runtime and monitoring views that are not part of the public venue |
| Contract governance and guardian rails | Pause flags, sensitive config, treasury permissions, and settlement protections |
#How authority is segmented
Public market reads, authenticated account views, restricted service routes, and contract-management paths should not share one permission model.
The gateway enforces those boundaries so broad product access does not automatically imply authority over sensitive operations.
The contract layer carries its own protections as well.
Governance ownership, guardian powers, pause flags, root guards, dispute settings, and related controls exist so sensitive transitions can be reviewed or stopped when necessary.
This is what makes the hybrid split real.
If the runtime could do everything and the contracts could stop nothing, then the design would only be hybrid in marketing language.
Dexter keeps authority narrow enough that a review can answer a simple question at every boundary: who is allowed to do this, and who is explicitly not allowed to do this?
public read != authenticated account read
authenticated account route != restricted operator route
restricted operator route != governed contract action
governed contract action != unrestricted runtime authority#What segmented controls achieve
These controls are not decorative.
They are what keep the venue readable when conditions degrade.
A compromised product read path should not automatically create treasury authority.
A runtime issue should not silently bypass withdrawal rules.
A governance path should be visible as governance, not disguised as ordinary product access.
That is the standard Dexter is trying to meet.