Accelerating the Listing Process for Fleets & Arks

General Discussion Feeback
,
1

Hey everyone,

I wanted to bring up an idea regarding the listing process for Fleets and Arks. Given that Lazy Summer Protocol is in growth mode, I believe our integration process should be faster to help us reach more markets, onboard more partners, and attract more users.

Right now, the listing process takes time due to governance and risk evaluations. While I agree that a thorough risk analysis is essential, I think we could introduce a faster listing framework that allows us to onboard new Fleets and Arks more efficiently, while still maintaining security.

Proposed Solutions

  • List new Arks quickly with a cap set at 0, allowing them to be added but not used until parameters are adjusted.
  • List new Fleets and Arks but keep them hidden in the UI (while setting the cap at 0), so they are technically integrated but only accessible when ready.

From my understanding, it’s easier for BlockAnalitica to update parameters than for governance to go through the entire listing process each time. By listing assets sooner (but limiting exposure), we can move faster without compromising risk oversight.

Potential Benefits

Faster Market Expansion – More integrations = more users, more liquidity, and a stronger protocol.
Flexibility Without Risk – Keeping the cap at 0 ensures no exposure while risk evaluations happen.
Reduced Governance Bottlenecks – Moving some of the decision-making post-listing can streamline the process.
Better Partner Onboarding – Faster listing decisions could make it easier to collaborate with new protocols.

Challenges & Considerations

:warning: Risk Perception – Even if the cap is 0, some might see this as cutting corners. How do we maintain trust?
:warning: Preemptive Listings – If governance ultimately rejects a Fleet or Ark after listing, could this confuse?
:warning: Governance Exhaustion – Frequent votes for new Fleets and Arks could overwhelm governance, making participation lower over time.

Possible Solutions for Governance Exhaustion

To avoid excessive governance votes while still maintaining decentralization, we could:

Delegate Listing Authority – Allow a trusted entity (like a risk council or core contributors) to handle preliminary listings at cap 0, only requiring governance votes for final activation on a daily basis (e.g weekly)

“Fast-Track” Process for Certain Arks – If an Ark meets strong liquidity, security, and composability criteria, it could be auto-listed at cap 0 without a vote, with governance only voting later to increase caps.

Minimum Listing Criteria

To ensure we don’t list assets with significant risks, we could introduce a lightweight due diligence step before allowing Fleets and Arks to be listed at cap 0. Some possible criteria:

Protocol/Token Age – The protocol should have existed for at least X months to ensure it’s not brand new and untested.
Liquidity Requirements – The token should have a minimum TVL or daily trading volume to ensure market stability.
Security History – Any previous exploits or hacks should be reviewed. If the protocol was exploited, what was the response, and were vulnerabilities properly addressed?
Audits – The protocol should have undergone at least two reputable audit or have a strong security track record.
Composability & Integrations – How well does it integrate with the rest of the ecosystem? Are there risks of dependencies that could lead to cascading failures?

This wouldn’t be a full risk assessment, but rather a quick check to ensure only reasonable candidates get listed before final risk evaluations.

Other refinements

  • Establish a Clear Activation Process – A structured, efficient way to increase caps (or not) post-risk review.
  • Transparent Communication – A public tracker showing pending activations could help maintain clarity. This can be a :warning: sign with a tooltip in the UI on the Unallocated tab under Vault Exposure.

Looking for Feedback

Does this approach make sense? Would it be an improvement over the current system? Are there other ways to balance speed, governance participation, and risk management?

2

I am supportive of this.

Adding a new ark from a protocol (i.e. Morpho) Summer is already integrated with is purely operational.

The risk assessment is done by the Vault Curator / risk manager.

I am supportive of the lightweight publicly available criteria for adding new arks, and allowing delegated individuals be able to add them without having to go through governance.

Separately,
integrating new protocols requires some technical implementation (deposit / withdraw / collect rewards), so that seems more like a Summer.fi team job.

1 Like
3

What’s available out of the box is:

I’ve added a simple readme file earlier today, explaining new protocol integration - in case anyone is interested in doing so. This would allow us to onboard new protocols more easily - or at least have the option to do so.

PS. Except the pendle arks.

1 Like
4

All in all a really good proposal which we support. Some thoughts here:

Risk perception: Every parameter update needs to be approved by voting anyway. We would recommend to BA to have the initial change from 0 to non-zero to be a standalone poll, so it can easily be defeated without affecting operations otherwise.

Preemptive Listings: There should be a simple offboarding process for Fleets and Arks to keep the product pipeline clean. The simple UX is one of the big selling points for Summer, and clutter is an enemy here. An easy way to keep it clean and simple is good.

Governance exhaustion: Couple of ways to prevent that. One is making these parameter updates optimistic, meaning that voters can veto the updates, but if they don’t cast a vote against an update, it passes. Done in many places with good success. Provides transparency and an easy way for voters to have a say, without requiring them to do so.

1 Like