Time Considerations

Sifcore facilitators will do their utmost to ensure that all work is prepared and can be done in the 1 hour synchronous meeting with the token listing council on Tuesdays. Votes may take place asynchronously.

Responsibilities

Approve / Deny Token Listings

• TASK: Approve or deny new token listings up until the launch of Peggy 2. The majority of these token listings will include liquidity partnerships from other projects. This further includes: suggesting new tokens that are currently not listed on the DEX to be listed, as well as determining token listings for token proposals from the community/other projects.
  • Example 1: Which cosmos tokens are not currently listed on the DEX that should be? Are there new projects that are coming up that we want to ensure we get them listed as soon as they go live? This is the ‘proactive’ part of listing new tokens.
  • Example 2: When a project wants their token to be listed, the council determines yes or no. When someone in the community submits a request for a token to be listed, the council determines yes or no. This is the ‘reactive’ part of listing new tokens.
  • DELIVERABLE:
    • A continuously updated list of tokens with yes/no indicated on them.

Determine Token Listing Order

• TASK: Determine the listing order of approved tokens. Now that we have a list of tokens that have been approved by the council, it is the council’s responsibility to determine in which order those tokens are listed. The council should review the ordered list of tokens each week and adjust the listing for any existing or newly added tokens to ensure the list is continuously updated.
  • DELIVERABLE:
    • A continuously ordered list of tokens to be listed on the DEX. This is then handed off to Sifcore engineering and will be used as the source for listing which token when. Sifcore will also pass along expectations to the council on listing dates to stay aligned on this endeavor.

Protocol Loaned Liquidity

• TASK: The council also has a budget of Protocol Owned Liquidity that they can use to provide liquidity to certain pools. The council would determine: how much and for how long that pool is bootstrapped with that liquidity. Again, this should be looked at as an investment on our side as well and one that: brings in more liquidity to the pool and/or earns the protocol rewards to sustain and grow.
  • DELIVERABLE:
    • Determination of which pools should get Protocol Owned Liquidity and how much. This is passed onto Sifcore to execute this liquidity provisioning. Then, weekly updates on how the investment is doing and if there needs to be any added/removed/adjusted.

Hiding un-used pools

• TASK: Determine which pools to remove from the FE of the DEX based on specific criteria. The council would determine: a set of criteria to use for removing pools from the FE of the DEX. These criteria would likely include: minimum TVL in the pool, “type” of token.
  • Example 1: Remove all pools with less than 10k liquidity
  • Example 2: Remove memecoin pools
  • DELIVERABLE:
    • Criteria for Sifcore FE engineers to use to delist pools from the FE of the DEX.