We’ve received requirements about listings on ICPCOINS @infu and would like to request for SLI to be listed.

  1. Code is Open-Source on github 5000SLICES/5000-SLICES-AND-GOLDSLICE-DIP20-STANDARDS at master (
  2. Canister is blackholed. Controller has been set to blackhole canister
  3. Our tokenomics has been published here: Internet Computer Loading
  4. We have communities on OpenChat, Distrikt, Twitter, DSCVR and Telegram. more information on our webpage :
  5. We have conistent high volume on ICPSwap.
  6. My SLICE INFO is the main project Coordinator (133) My Slice Info - YouTube

Thank you for your consideration and let us know if you need anything else.

1 Like

I was envisioning something similar to when suggesting people post about their tokens in this forum. Now it feels like a bad idea. Perhaps putting these in Taggr will be better - unless your token does something technically interesting to fit a developer forum.

1 Like

I understand what you mean. I can see how it seems like a bad idea to post in forums to get approval for token listing. It would be better to create a form --google or something for token owners to complete. ICPCoins is your project and a public one so there is need for an efficient way to screen tokens to be listed. As a Dex aggregator-- I do not even honestly see why it should be such as hassle to get tokens on there unless of course they clearly present risks. It’s the job of Dexs to be more rigorous in screening tokens-- not a Dex agregator. It’s like if CoinMarketCap were on ICP, only specific tokens would be listed there.

Let’s call it a miscommunication. What we meant was for you to post information about the token where the community can see what it’s about, not to ‘request’ a listing. That can easily be fixed by changing two sentences in your post. Btw the Github link doesn’t work.
Icpcoins is a stats site, not a token authority. Until we figure out how to make it scale to hundreds of tokens and thousands of pairs, we have to be selective.
Once it becomes a DAO, we will still prefer if all listings go through proposals.

Github link wasn’t working. solved :GitHub - 5000slices1/5000slices-Goldslices-Dip20-standards at master

Well understood, but then, the decision isn’t up to the community-- It was a DAO, not anymore and until then, I think you make the decisions.

It was in a DAO, yes. Then we got it back and will eventually put it in its own DAO again.
Until then, someone has to do at least some basic checks to ensure the tokens added aren’t (napkin ledgers) - as good as someone keeping balances in Google spreadsheets and freely writing whatever they want inside.
A proper audit costs tens of thousands. We are just doing very minimal checks for free in service of the community, which are not an audit and don’t guarantee anything, but can quickly reveal if something is very wrong.
After a 5-minute check. In your case, your 5000 limited token that is blackholed - isn’t true. In this case, blackholing doesn’t mean anything.

You have a minting function and the ‘owner_’ can mint an unlimited amount of tokens freely.
Your contract doesn’t publically show what the ‘owner_’ is set to.
Your ledger is pretty much toast with not much you can do to fix it.

Controller set to e3mmv-5qaaa-aaaah-aadma-cai ( a blackhole canister) Verify on ICPSwap ICPSwap There is just one controller and that’s the blackhole canister.

There is no way to mint more tokens when controller has been set to blackhole canister controller.

The owner_ is not the controller in your case. It is set when installing/upgrading the canister

We will convert to ICRC-1 after staking period. We had already made plans for that. Your input is appreciated. It opened up a Chanel I didn’t think of.

As a workaround, a very hacky way of getting out of your situation, if you still have the owner_ set to an identity you own - you can create a canister (checking canister) that does the following:
initially var status = 0 (don’t make it stable)
a function tries to use the setName of your ledger and if that throws an error, you set status = 1
if it doesn’t throw error set status = 2
Have a function that shows what the status is.
Use setOwner to put the checking canister as owner_
Run the function that does the check.
If status is 2 you have proven the checking canister is the owner
Provide the source of the checking canister so it compiles to the module hash installed.
Blackhole the checking canister.
The result - You have proven the owner_ is now ‘bricked’ and more tokens can’t be minted (At least not through this vulnerability)

Thank you! This turned out a learning experience.