Psychedelic TownHall

Psychedelic TownHall 01

This Thursday, July 14th at 1:00 pm EST, we’ll be hosting Psychedelic’s first community Town Hall. This will be the first of a new series of live bi-weekly meetings where we’ll discuss important and pressing topics within the IC community and the Psychedelic ecosystem as a whole.

With our presence and product suite within the Internet Computer ecosystem, Psychedelic is looking to become a more involved community steward. We want to help guide the future of this community, and with your help, open discussions on how we can improve it!

TownHall 01 Structure

Our first TownHall will be structured as a talk more so than a discussion, with dedicated time for questions at the end. It will take place through a Twitter Space.

Planned discussion topics for TownHall 01:

  • Laying out our vision and wishlist for the Internet Computer
  • Address community discussions surrounding Psychedelic
  • SNS & Token standard critiques

Going forward, Psychedelic TownHalls will be an open-floor style discussion that encourages community participation.

We’re Psyched to see you there. Sign up to be notified about the Twitter Space here.


Quick formal reaction to the great town hall that Psychedelic did today. A couple of affirmations and a couple of critiques.

We need discussion like this - some of this was critical to the DFINITY Foundation, but critique is healthy and in helping any organization get better.

All eyes on the foundation - The foundation has assembled such an amazing set of researchers, programmers, and crypto experts that all the eyes are justifiably on them. When they speak people listen and when they say something will happen, everyone who was working on that thing stops. Supernova took everyone’s attention in a good way…the community needed that bump. A few other initiatives have moved all the eyes onto a single solution and keeps others from engaging in experimentation. It is both a blessing and a curse and I don’t envy the foundation in trying to make the decisions about when to step up and when to let the community run. It is hard! So I hope the foundation can take the critiques in a positive light and work to better identify when they should step in and when they should let the community run with things.

Psychedelic’s suggestion was that the rubric to use should be stick to 1. Stick to the protocol level and 2. You can’t/shouldn’t solve every issue at the protocol level. I don’t know that that is the right rubric, but I also don’t have a better suggestion. When the Foundation says they are going to solve a problem all but the most well-funded outside contributors stop working on that problem. When the SNS was announced work on DAOs from the community drastically fell. I think maybe Origyn and FlowerPowerDAO are a couple of the few that took a swing at the plate. In helping Origyn I’ve learned how insanely hard they can be and what nuance is necessary to keep them going.

That brings us to the SNS. I’m a Min/Maxist on the SNS. I think it is an amazing solution in 5 years, but an extremely dangerous thing to accelerate in the short term. I don’t have any insight into the actual timing DFINITY has, but it FEELS way too fast. If we’ve one of these protocols securing hundreds of millions of dollars for an extended period of time and demonstrating competent and functional governance, we could absolutely consider elevating it and putting it under the purview of the NNS, but to my knowledge that is not the process that is being proposed. We haven’t even proven that the DFINITY network is well tuned to support the PoS model for on-chain governance. We are currently voting on Internet Computer Network Status which specifically pits short-term gain vs. long-term health of the network and short-term gain seems to be competing to a level that might undercut the fundamental assumptions about how this on-chain governance stuff is support to self-balance itself.(There is lots of nuances here that we can/should debate over on the appropriate thread)

On the other hand, I’m very bullish on the DFINITY foundation publishing audited and working contracts that other people can fork and experiment with. They have the resources to build great code and then release it into the wild.

How do you walk back where the SNS is right now? Release the open source contracts for SNS ledger, SNS governance canister, SNS Swap canister with strong defined and decoupled interfaces between them. Let 50 DAOs select the pieces they want and experiment with others. Give us a rust + motoko ledger and a rust + motoko governance canister and a rust + motoko swap canister and let us fiddle with them. Once we have lessons learned we can talk again about promoting things to the NNS and if that is a good idea or not.

To push back on Psychedelic a bit I raised that the ICRC-1 standard was very much community-led. ORIGYN pushed very hard for some attempt at a solution to the many-standards problem after implementing the OGY token with Sonic. This was way more complicated than it should have been for the sole reason that DIP20 and the IC Ledger Canister both use “transfer” as a function name. Our request for a solution coincided with other community desires and DFINITY agreed to run the workshops. I think this is/was a good use of DFINITY’s power. They have done a decent job of listening. The pressure for burning in the standard for the purpose of the SNS is not a great pressure to have, but in general, I think the working group has made some good progress. The goal is maximum interoperability. In the last meeting, we discussed making sure we present a narrative that while there is a “base standard” there are also “Recommended Extensions” that provide maximum interoperability with other pieces of the IC. Those are 1. Approval/TransferFrom, 2. Transfer and Notify, and 3. Query Blocks. Other optional extensions like a rosetta extension were also discussed. We also discussed(and are still discussing) having the SNS team commit to implementing those recommended extensions on a timeline so they can move forward and the rest of the community can begin to prepare for a maximally interoperable world.

Psychedelic has indicated that they are open to namespacing(which would likely make the need to have “1” standard unnecessary and enable health competitive innovation). I’ve discussed how this can be used on a go-forward basis by both EXT and DIP20 just 1. adding namespace functions 2. using them as wrappers for the current functions and 3) removing the unnamespaced functions from the documentation. This solution would be almost no new code(and certainly very safe code to add) and I’ve talked about it before(Proposal to Adopt the Namespaced Interfaces Pattern as a Best Practice for IC Developers).

I don’t think we need to re audit:

Public shared(msg) transfer_dip20(principal, amount) : async Nat {
	return _transfer(principal, amount;

Public shared(msg) transfer(principal, amount) : async Nat {
	return _transfer(principal, amount);

They also indicated that they wished that DFINITY had tried to improve an existing standard. I think the ICRC group was being pretty accommodating to the things that Psychedelic was bringing and trying to come up with good accommodations that also preserved some of the power of the IC(like sub-accounts that canisters might want to use because they can’t natively have multiple principals). I don’t think any on the ICRC-1 working group is tied to calling the thing ICRC-1 over DIP20 2.0. The concepts also map 1:1. If DIP20 concedes on sub-accounts and DFINITY concedes approval flow, don’t we have a win and the name on the thing is irrelevant? Transfer and notify can come in DIP20 2.1. There are real and important use cases for transfer and notify.

I’ll also push back on the idea that we should do wrapped tokens just because ethereum does it that way. This came up during the town hall with the suggestion that DFINITY was motivated by a desire to not have WICP. In general, the IC is much more powerful than other chains, and limiting ourselves to previous patterns that emerged due to a single “shard” and limited gas set us up to fail by choosing not to use the superpowers we have at our disposal. From my personal experience, there was an intense desire to not have the OGY token wrapped when interacting with DeFi from our leadership team. We wanted the token itself to be used. In simple scenarios like a fungible token, wrapping is a convenience and an accident of implementation. I think it ultimately ends up being bug because once you go to any kind of complexity(and the IC enables complexity), wrapping is a way to route around the intended logic of the underlying smart contract. A simple(maybe dumb) example would be a token that wants to support some feature based on a transaction tax(like a sales tax). If you wrap the token and trade the wrapper the smart contract can’t operate as intended(we are about to see this problem when neurons become trade-able once ecdsa lets canisters hold neurons. Creating wrapping resistance is hard but will ultimately enable more complex and useful smart contracts.

That wasn’t very quick or formal. Sorry about that. Hopefully, we can keep having constructive conversations about this. The community will only get stronger if Psychedelic communicates more and lays out their reasons. There is a TON of lessons learned in that organization that we all can learn from.

Thanks for contributing to the conversation and moving it forward.


I want to give a bit of context on this. The ERC20 approve/withdraw flow was introduced because a lot of transferred tokens got irretrievably lost because the smart contracts just were not aware of their balances in various token contracts. The ETH balance on the other hand is directly integrated in the Ethereum state. Then we got a lot of different ERC20 tokens and DEXes became popular. Then it got annoying to implement special flows to handle ETH and wrapped ETH became a thing.

On the IC the situation is a bit different. From a technical perspective, the closest thing we have to ETH on Ethereum are Cycles on the IC. ICP itself is not part of the system but implemented as a regular canister and everyone is able to deploy their own token with the same interface as ICP.


Hi! Thanks for the TownHall, loved it!

I want to comment on the second episode:

There was a lot of critique of the Internet Identity, most of it well deserved.
As a person intimately familiar with the conception of the II service, I’d like to provide some historical background.

  1. As many developers learned the hard way, the II derives a unique, unpredictable principal for each domain. That was a conscious decision. We considered having user-picked profiles modeled after browser profiles (I wanted this design particularly badly). Still, we decided to go for maximum privacy by default. Some people love this feature, but I’m not one of them.
  2. The UX of the service is not great indeed. Unfortunately, we didn’t have time for UX studies at the time: we had only two weeks to implement the first version of the II service, from the conception of the protocol to the functioning service! The II team improved the UX substantially over the last year, but some of our early decisions still bind them.
  3. It’s hard to see with a naked eye, but we invested a lot of effort to make II not unique in any way: anyone can brew their identity provider with different privacy trade-offs. If you crave diversity and don’t like II — stop complaining and build your service! The only problem is that it’s impossible to transfer an existing II anchor to another provider, but there are plenty of new users to attract.

Finally, the recent DIP-20 proposal for subaccounts (DIP20 Community Proposal (PsychedelicDAO)) goes against the Web3 values you admire so much: the transparency and ability to link information freely. Allowing canisters to masquerade their identity based on who they talk to looks suspiciously similar to the Internet Identity design.