(1) Protocol-level fee / treasury mechanism
Introducing a protocol-level fee redirected to a treasury would change the nature of the mechanism.
The current design keeps:
-
reward distribution proportional and directly tied to stake,
-
no additional protocol-controlled redistribution layer.
Adding such a mechanism would introduce governance over redistribution and move away from a neutral protocol primitive toward a policy-driven system.
This may be explored separately, but it is out of scope for the initial design.
2) Alternative governance for sTEZ bakers
The design intentionally avoids introducing:
-
additional voting rights,
-
or parallel governance layers tied specifically to sTEZ.
The guiding principle is:
liquid staking increases economically committed stake participating in consensus, without introducing new governance rights.
In practice:
-
sTEZ contributes to consensus through the underlying stake allocated to bakers,
-
but it does not create a separate source of voting power or governance influence beyond what that stake already represents.
Introducing governance rights tied specifically to sTEZ (or to sTEZ bakers) would:
-
duplicate or distort existing governance mechanisms,
-
and reintroduce risks of governance concentration through liquid staking.
So the current design keeps a strict separation:
-
economic participation in consensus → increased via sTEZ
-
governance rights → unchanged and governed by existing mechanisms
This separation is intentional for the initial design and helps keep the mechanism predictable and neutral. Whether additional coordination or governance surfaces around sTEZ make sense could be revisited in later iterations, once the core mechanism has been exercised and evaluated.
(3) Liquidity Baking integration
This sits at the intersection of protocol economics and application-level integration.
While some mechanisms (e.g., minting via tickets, rollup interactions) are technically feasible, embedding such integrations directly in the protocol would introduce tight coupling between otherwise independent components.
The current approach is therefore to:
-
define sTEZ as a protocol primitive,
-
and allow integrations (e.g., AMMs, rollups) to build on top of it.
