Why should I trust tokens launched under SNS?

[blockpunk]

@skilesare

Stop waiting and start building. The NNS ledger works. You can fork it. We did. Our token is live. Just do it. We already have a standard developed by DFINITY and it is securing $2B worth of ICP.

Glad to see you guys are making it work, I’ve used origyn’s tokens.I also think developers shouldn’t wait for SNS, because SNS still follows the ICP ledger design, which doesn’t work well with many current DeFi services. DEVS can deploy token contracts in the application subnet first, and then transfer to SNS when appropriate.

@skilesare

It is up to the canister developer to provide this. All the tools are there. The NNS Ledger provides full history and crypto verifiability. I’m not sure what you mean about “preventing container from forging users” but canisters being able to hold your token is a feature not a bug. That is how you build apps on the IC. A smart contract can hold ETH, why not a canister holding ICP?

You can read Why should I trust NNS Ledger, seriously?. The transaction information of NNS’s ICP ledger canister is stored in archive conisters, but this conisters do not save the user’s signature and authorization records, the controller of the ledger canister can forge a transaction that has not been initiated by the holder by maliciously upgrading to achieve an attack. ICP Ledger canister has this ability, but we believe it will never happen (because of the decentralization of governance), and the situation is different for the token of early SNS. So the ledger canister design that follows the NNS cannot be cryptographically self-verifiable yet. This is also a point I did not discuss above

@skilesare

Use the same paradigm as the NNS ledger and submit your canister to decentralized governance. This is what the SNS is going to try to enable, but there is nothing stopping you from doing it today. We’ve launched a governance canister and will soon have upgradeability integrated with governance so that upgrades can’t happen without a vote.

It took ICP a long time to push hard for decentralization, which is why we trust NNS, and for early projects, decentralization is not so great that governance often doesn’t work, and some developers will prefer to keep the ability to update the contract to fix bugs and avoid being attacked. The economy of early dapps is very fragile to operate prematurely giving all container controllers to a black hole address or a dao is not a good thing.

@skilesare

Approve/Transferfrom is broken in ethereum and can be front run to cause massive problems. Most implementations actually break it and don’t follow the actual standard because of this.

As I said before, approve/transferFrom is great for preventing double payments. The point is that it’s easier for developers. We currently focus more on usability, and the design of SNS is not easy for developers to handle. In the current use case, it is clear that more developers choosing WICP. And the method of deposit is not in line with the habits of crypto users. Although their habits are all shaped by ETH DeFi, this transition will take some time, and we obviously need LFG now.

@skilesare

We have a 600 line approve/TransferFrom proxy canister that works with a slightly modified NNS ledger. The NNS part is already open-sourced and we’ll have the proxy out soon.

This sounds very useful, hope to test it sooner. But proxy servers actually introduce new risks, why can’t we make it simpler? Maybe we can influence community and foundation to make some better optimizations.