Featured App locking after tokenomics review: a 30-day lock window before governance

1. #1Abdulkadir CANPOLAT19-10-2026source ↗
   Hi all,
   
   This proposal moves the Featured App lock from before the tokenomics review to after it, with a 30-day window to lock before governance.
   
   1. Context
   
   Under CIP-0116, an application must lock CC to become a Featured App. Today the lock is expected before the application is reviewed. A team has to commit capital before anyone has assessed whether the app is a fit for the network.
   
   2. The problem
   
   - The lock filters applicants on capital, not on quality. A small team with a strong product and no spare budget is stopped at the door, while a well funded team with a weak product passes this step.
   - Builders who are not institutions either lock capital they need for development, or stop building on Canton altogether. Both outcomes cost the network apps it would want.
   - Review teams carry the full workload of every application, including those that will never reach governance.
   
   3. The proposal
   
   Move the lock from before the review to after it, with a fixed window:
   
   Step 1. The team submits its Featured App application. No lock is required at this point.
   Step 2. The tokenomics review takes place as it does today.
   Step 3. If the review is negative, the process ends there. Nothing was locked, nothing needs to be returned.
   Step 4. If the review is positive, the team has 30 days to complete the lock required under CIP-0116.
   Step 5. The application goes to the governance vote only once the lock is in place and visible on chain. No lock, no FA approval.
   Step 6. If the 30 days pass without a lock, the application lapses. The team may reapply, but the new application is accepted only if it clearly explains why the lock could not be completed the first time. Without that explanation, the second application is not accepted.
   
   4. What stays the same
   
   - Every Featured App still has its full lock in place before governance votes on it. The network keeps exactly the same guarantee.
   - The lock amount, duration and conditions stay as defined in CIP-0116. This proposal changes only when the lock is required.
   - The review criteria do not change.
   
   5. What improves
   
   - Quality comes first. The review decides who moves forward, capital only confirms the commitment afterwards.
   - Builders without upfront budget get a real path. They can show the product first and arrange the lock once they know it has passed review.
   - Reviewer workload stays protected. The reapply rule stops the same application from cycling through the queue, and a team that passes review and then fails to lock has to justify itself before it is looked at again.
   - Capital is locked only where it leads somewhere. Nobody locks CC for an application that is then rejected.
   
   6. Possible concerns
   
   "Teams could use the review for free and never lock."
   The review result alone gives them nothing: there is no FA right without the lock. A team that lets the window expire must explain itself to reapply, and repeated lapses are a clear signal to reviewers.
   
   "30 days may be too short or too long."
   We are open on the length. 30 days is long enough to arrange funding or a partner, and short enough to keep the queue moving.
   
   "Does this weaken commitment?"
   No. The commitment is identical. It is simply asked for at the point where it is meaningful: after the network has said yes to the app.
   
   7. Questions for the list
   
   - Is 30 days the right window, or should it scale with the size of the lock?
   - Should a lapsed application return to the start of the queue, or keep its review result for a limited time?
   - Is there a reason the lock needs to precede the review that we are not seeing?
   
   We would especially welcome views from the tokenomics reviewers and the SVs.
   
   Thanks,
   Canpolat
   The Hub (thehubcc.io)