# RFC TEMPLATE: Request for Comment

**URL:** https://forum.summer.fi/t/rfc-template-request-for-comment/260
**Category:** Resources and Tutorials
**Tags:** rfc, guide, template
**Created:** [June 21, 2025, 12:24pm UTC](https://forum.summer.fi/t/rfc-template-request-for-comment/260 "2025-06-21T12:24:40Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)
#### Post date: [June 21, 2025, 12:24pm UTC](https://forum.summer.fi/t/rfc-template-request-for-comment/260/1 "2025-06-21T12:24:40Z")

</div>

> Use this template when sharing an early-stage idea with the community. RFCs are informal and non-binding but crucial for early input and iteration before becoming a SIP.

* * *

### Title:

`[RFC] Title of Proposal Here`

> Use this formatting when creating a new topic:  
> ![image](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/4db08f7b13ff3a709c1190a2730531ce338c1acc.png)

`Select appropriate category, and add tags for improved searchability.`

* * *

### 0. Baseline ARK Criteria:

@BlockAnalitica as the risk curator of the Lazy Summer Protocol, has shared the best practices for recommending new ARKs (strategies) to be added to the existing FLEETs (vaults).

`Please, read through, consider and include this assessment in your proposal. This is only applicable to recommending/introducing new ARKs to the protocol.`

> [@BA Labs baseline criteria for recommending new ARKs](https://forum.summer.fi/t/ba-labs-baseline-criteria-for-recommending-new-arks/567):
>
> BA Labs baseline criteria for recommending new ARKs Here we outline the “first rule” checklist BA Labs will use before doing any deeper collateral assessment when recommending new ARKs for Lazy Summer Protocol. Only ARKs that pass these baseline criteria move to a full collateral and risk review, unless we explicitly state why we are making an exception. BA Labs reserves the right to modify or omit any of the below, while providing a clear rationale for any such changes or exclusions. This shoul…

* * *

### 1. Summary:

`A brief, one-paragraph summary of what this RFC aims to solve or change. Think of this like a TL;DR.`

`Tag forum username(s) if the proposal is co-written.`

* * *

### 2. Context & Motivation:

`Why this RFC matters. What current problem, limitation, or opportunity is being addressed? Reference existing RFCs/SIPs, community discussions, or protocol parameters if relevant.`

* * *

### 3. Proposal:

`Describe your initial proposed solution, design, or direction. It’s okay if things are still in flux. This is where the community can help co-develop it. Include specifics where possible (e.g. affected parameters, changes to roles/processes).`

* * *

### 4. Open Questions:

`List any unresolved issues or items you’d like community input on. This is a great way to focus discussion.`

* * *

### 5. Next Steps:

`* Gather community feedback`  
`* Iterate based on discussion`  
`* Promote to SIP (with clear, formal specification)`

* * *

### 6. Informal Support Indicator (\*_optional_):

`Based on the [RFC] posted by StableLab it is suggested to use a non-obligatory signal via polling as a way to gauge community sentiment.`

> [@Forum polls for proposal support signaling?](https://forum.summer.fi/t/forum-polls-for-proposal-support-signaling/291/1):
>
> Creating them is super easy, just click the plus sign at the right end of the toolbar and select Add Poll. Votes public, Yes/No, or whatever options you think are good.

 ![Frame 427321376](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/5a03fbb6d50f55afb5b5193e0b524a3e3bbf1152.png)
