Freeze Authority Library

Note. This specification describes an outcome that may benefit the Logos ecosystem. It is a proposal rather than an instruction. Its requirements reflect the technical compatibility with the Logos technology stack and are the criteria against which proposals and milestones are evaluated. Logos makes no representation as to the legal or regulatory treatment of this specification or any implementation of it in any jurisdiction.

Teams implementing it are solely responsible for (i) assessing the risks and implications of what they build; (ii) obtaining their own professional advice; and (iii) for complying with any legal and regulatory requirements that apply to them. Software developed under the Program is published and maintained by its developers, not by Logos.

Anyone who chooses to deploy, host, operate or use software developed under the Program, whether or not they were awarded a grant under the Program, does so at their own risk and is solely responsible for complying with any legal or regulatory requirements that apply to them. See the Terms & Conditions.

Deploying the software described in this RFP, operating any service based on it, or carrying on business through it may amount to regulated activity in some jurisdictions, including where it involves holding or managing users' assets or providing services to others. Whoever conducts any such activity does so as principal, in their own name, and is solely responsible for assessing its regulatory treatment, including any licensing, registration, sanctions or anti-money laundering obligations that may apply to them. Logos does not make any representation, provides any advice or assumes any responsibility in respect of any such determination or compliance.

🧭 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.