Freeze Authority Library

🧭 Overview

Build a reusable library that provides a standardised freeze mechanism for LEE programs, allowing an authorised account to disable all (or selected) interactions as a circuit breaker when an issue is discovered.

The library must be integrated into the SPEL framework and ship with documentation and usage examples so teams can enable the pattern with minimal boilerplate.

🔥 Why This Matters

As the Logos ecosystem grows, programs deployed on LEZ need foundational security primitives from day one. Without a standardised emergency stop mechanism, every team must design their own — leading to inconsistent implementations, duplicated effort, and a higher risk of critical vulnerabilities.

Delivering this as a shared library lowers the barrier for developers building on LEE. Teams can focus on application logic rather than re-inventing freeze patterns, accelerating the pace at which new programs ship. As more programs begin handling real value, the ability to freeze a compromised program is the difference between a contained incident and a catastrophic loss.

✅ Scope of Work

Hard Requirements

Functionality

1. Freeze authority can be set at program initialisation.
2. Freeze authority can be changed by admin authority.
3. Freeze authority can freeze the program, rejecting any attempt to interact with it; apart from unfreezing or changing the freeze authority.
4. Freeze authority can un-freeze the program, re-enabling interactions.
5. Freeze authority can be revoked by admin authority.
6. Freeze authority can freeze a specific account by AccountId, preventing it from interacting with the program while leaving the rest of the program operational.
7. Freeze authority can un-freeze a specific account, re-enabling its interactions with the program.

Usability

1. The library is integrated into the SPEL framework so that programs using SPEL can enable freeze authority with minimal boilerplate — ideally a single annotation or configuration flag.
2. There can only be one freeze authority (signer) at a time.
3. Documentation includes at least one end-to-end usage example showing how a SPEL program integrates the freeze check.

Performance

No compute budget constraints are expected for this library. Document the additional transaction size overhead introduced by the freeze check on any gated instruction.

Supportability

1. CI must be green on the default branch.
2. Every hard requirement in Functionality, Usability, and Reliability has at least one corresponding test.
3. A README documents how to add the library as a dependency and integrate it into a SPEL program, including a step-by-step example.
4. A sample program that imports the library is included to validate the integration path and serve as a reference for consumers.

Soft Requirements

If possible.

Reliability

1. Freeze authority can only be set to a valid new signer (on-curve key or deployed PDA), when set or initialised.

👤 Recommended Team Profile

Developer experienced with:

• Solana or SVM program development (Anchor or native)
• Access control and authority patterns in on-chain programs
• PDA derivation and account validation
• Writing and running on-chain tests (e.g. Bankrun, Anchor tests)
• Library/crate packaging and documentation

⏱ Timeline Expectations

Estimated duration: 4 weeks

🌍 Open Source Requirement

All code must be released under the MIT+Apache2.0 License.

Resources

• SPEL framework
• TODO: LEE official doc

✏️ How to Apply

👉 Submit a proposal using the Issue form:

Submit Proposal

We typically respond within 14 days. For clarification questions, please use Discussions.