---
title:
author:
description:
---

# Implementing Candle Auctions on Referenda's Confirmation Period

## Overview

While OpenGov is a huge advancement in terms of building a decentralized solution for on-chain governance, some features in its design can be used to take advantage of some unwanted behaviours. One of them is snipping: in this case, being the last actor to ever vote in a poll while in *confirmation period*, thus drastically affecting it's status, ignoring the overall result (both on decision period AND mostly all the confirmation period).

Since decision and confirmation periods are now extended, having this kind of behaviour leads into an expensive outcome when an otherwise passing poll gets rejected last minute and needs to be reintroduced from the beginning.

This feature request aims to find a solution, using a concept similar to **Candle Auctions**, but intended for determining the state of the poll within the confirmation period.

## Proposed Solution

The current state flow for the referenda protocol goes like this:

stateDiagram-v2
    sb: Submission
    pp: Preparation Period
    dp: Decision Period
    cp: Confirmation Period
    state dpd <<choice>>
    state ps <<choice>>
    cf: Confirmed
    rj: Rejected

    [*] --> sb
    sb --> pp
    pp --> dp: decision period starts
    ps --> cp: proposal is passing
    dp --> ps: proposal meets passing criteria
    dp --> ps: decision period ends
    cp --> dpd: proposal fails
    dpd --> dp: decision period not deadlined
    ps --> rj: proposal is not passing
    dpd --> rj: decision period deadlined
    cp --> cf: confirmation period ends
    cf --> [*]
    rj --> [*]

The proposal is to modify it, so, if the decision period has deadline, the proposal is not immediately rejected once failing, but instead, wait until the confirmation period finishes to define a random moment in time between confirmation period starting and confirmation period ending where it determines the state of the proposal at that moment. Something like this:

stateDiagram-v2
    sb: Submission
    pp: Preparation Period
    dp: Decision Period
    cp: Confirmation Period
    cds: Candle Auction
    state dpd <<choice>>
    state ps <<choice>>
    state cd <<choice>>
    cf: Confirmed
    rj: Rejected

    [*] --> sb
    sb --> pp
    pp --> dp: decision period starts
    ps --> cp: proposal is passing
    dp --> ps: proposal meets passing criteria
    dp --> ps: decision period ends
    ps --> rj: proposal is not passing
    cp --> dpd: proposal fails
    dpd --> cp: decision period deadlined
    dpd --> dp: decision period not deadlined
    cp --> cds: confirmation period ends
    cds --> cd: define moment when candle lit-off
    cd --> cf: proposal passed at that moment
    cd --> rj: proposal did not pass at that moment
    cf --> [*]
    rj --> [*]

## Proposals

1. Implement the [Auctioneer][trait:Auctioneer] trait from `polkadot-runtime-common` crate on `pallet-referenda`.
2. Reimplement the candle auctioneer mechanism, adapted to `pallet-referenda`.

### Trade-offs

1. By implementing the [Auctioneer][trait:Auctioneer] trait on `pallet-referenda`, it'll be necessary to define an adapter between polls' passing status and the auctioneer's bids. While it's true that this guarantees maximum code reusability, a further development will be needed to determine whether this approach might take even more time than reimplementing.
2. By reimplementing the candle auctioneer mechanism on `pallet-referenda`, some code duplication, and potential timing might be incurred as a result.

## Project Structure and Deliverables

The project will be divided into three milestones:

1. **Milestone 1**: Design and implement candle auction mechanism on `pallet-referenda`.
- **Deliverable 1**: A fork of `polkadot-sdk`, featuring the changes on `pallet-referenda`, to be peer-reviewed, with proper testing, and benchmarking functions.
1. **Milestone 2**: DRY on Kusama Runtime.
- **Deliverable 2**: A forked version of Kusama (maybe using Chopsticks?) that evaluates a runtime upgrade that includes this change.
3. **Milestone 3**: Deploy on Kusama Runtime and Polkadot Runtime.
- **Deliverable 3**: RFC to propose the mechanism, and forward the change.
- **Deliverable 4**: Issue on `polkadot-sdk` to upstream this change.
- **Deliverable 5**: Issue to upgrade Kusama Runtime. Technical assistance to support this issue and its implementation.
- **Deliverable 6 (optional)**: Depending on the results of Deliverable 5, Issue to upgrade Polkadot Runtime. Technical assistance to support this issue and its implementation.

[trait:Auctioneer]: https://docs.rs/polkadot-runtime-common/9.0.0/polkadot_runtime_common/auctions/pallet/struct.Pallet.html