12 Holhos - An ICDevs Fundraiser

Hello #IC family.

Today is my 45th birthday and I’m running a fundraiser for ICDevs. Since I’ve now crossed into old man territory I have 12 spicy hot “man yelling at clouds” hot takes to relay, but I’m only going to release them in conjunction with raising funds for ICDevs.

What is a Holho? It is a Highly Opinionated, Lightly Held Option. These are good for discussion but are not dogmatic stances by any means. You’d likely be able to talk me off my position here with good arguments and clear thinking.

This is supposed to be fun and all opinions should be taken with a grain of salt. We’re trying to have fun here and fund some developers on the IC while we watch the web3 world burn.

Edit: Make the scale steeper.

  1. (Replicas) - DONE - 12 Holhos - An ICDevs Fundraiser - #2 by skilesare
  2. (Maturity) - DONE - 12 Holhos - An ICDevs Fundraiser - #3 by skilesare
  3. (Programming) and 4. (Programming) – DONE - 12 Holhos - An ICDevs Fundraiser - #6 by skilesare
  4. (Interoperability) - 250 ICP
  5. (Governance) - 400 ICP
  6. (Outreach) - 600 ICP
  7. (Neurons) - 1,000 ICP
  8. (Tech Priorities) - 3,000 ICP
  9. (Psychedelic) - 10,000ICP
  10. (Toniq) - 20,000 ICP
  11. (Origyn) - 80,000 ICP - ICCon in Austin, TX - Early 2023


Opinions are my own and should are not the official positions of ICDevs.org or Origyn. Most relevant decisions at ICDevs are made by the Dev Advisory board and Origyn is controlled by the Origyn Foundation.

Donations are tax-deductible for US Citizens and corporations. Let me know your donation details and I can issue you a tax note.

Why should you care what I think?

Here’s what I’ve been doing lately and why I think I have some insight into what the IC “should” do:

  1. Since 2018 I’ve been talking to Fortune 500 companies about how to onboard crypto with DFINITY’s tech specifically in mind.
  2. I’ve run ICDevs for the last year. I’ve tried raising funds (fairly unsuccessfully) in a bear market for funding developers of much-needed open-source public goods infrastructure on the IC. I’ve participated in at least two major hullabaloos over governance and been accused as a rent extractor, capitalist, and a CIA level conspiracy operative.
  3. I’ve completed 3 different DFINITY grants across two different organizations.
  4. I’ve been the CTO of the Origyn Foundation and we’ve A) Launched a token on the IC and had it placed on two public exchanges and DEX. B) launched an open-sourced NFT standard that leverages the power of the IC for next-generation NFT interaction and experiences C) Written a governance structure for the ORIGYN network and designed an evolution of that platform.
  5. Over the last few months I’ve attended ethMexico, the Stanford Blockchain Summit, and DevCon in Bogota and endured enough people saying ‘you are the first person I’ve heard of building on the IC’ enough times to drive me crazy enough to have these highly opinionated opinions.

The fundraising goal is ambitious, but heh, 80,000 ICP isn’t what it used to be.

As always with ICDevs donations, 2/3 goes into the permanent treasury(8 year neuron), 2/9 goes into the community fund for bounties, education, and community-building activities, and 1/9 goes into administrative activities. Most admin activities to date have been paying lawyers and accountants. Eventually, we’d like to hire full-time staff that can do community building and development.

Donation Address: 9f65a13064f16d444af9975ee1bca01eded559d6f753b58a43cfeb8a9617436d

Track donations here: Internet Computer Network Status

More donation info: ICDevs.org

I’ll use the forum as the reference location for these Holhos, but will also post them across twitter/IC Social Networks.


20 ICP! Here is HOLHO #1

Dfinity should fund the development of an alternative(JavaScript) replica and nodes should be given the choice of which to run(barring performance impossibility).

Having only one version of your replica software is a know blockchain weakness. The EF prioritizes having multiple clients written in multiple languages o that if one of the clients has a show stopping bug, the network can continue on. Since the IC needs 2/3 consensus, we probably need 4 clients for maximum safety.

This is expensive, but also like not an expanse that can be avoided. It also has advantages that far outweigh risk reduction. If you have multiple teams building your replica software in four different languages, you likely have exponentially more good ideas being shared, many more devs rotating in and out of those teams that have a fundament understanding of how your damn chain actually works, and increase the serendipity of good ideas spreading to other orgs by an exponential factor.

I’d suggest that we start with JavaScript as it will reach the most devs in the shortest amount of time. Does this delay your upgrades some? Yes it does. But it also makes you more disciplined about what features you commit to.


70 ICP! Here is HOLHO #2.

This is a spicy one and 100% colored by my attempts to raise funds in a bear market:

We should remove merge maturity from neurons and make everyone either pay taxes or off set their gains with expenses back into the community.

Tax avoidance is stupid and lowers the velocity of ICP. We should force stakers to either form for-profit orgs that can offset gains with expenses or encourage donations to non-profits that can invest in the ecosystem.

Taxes suck, but there are many ways to avoid those. Simply by forming an organization that works on the IC, you can turn the expenses you incur by building for the platform into losses that offset your staking profits.

There are also charity non-profits like ICDevs.org that will do this for you to a certain extent and up to a threshold. Maybe you should start one in your jurisdiction that benefits your tax treatment?

The key here is that by forcing people to claim their ICP dividends as ICP it forces an action. If we all just hodl and mergle there will never be any ICP available to builders. I get it, merging is an easy way out and the returns are really nice(as long as the price isn’t falling 90% while you stack at 20%). But right now everyone is taking the easy way out. Maybe a few VCs are stepping up, but is that who you want leading the new internet?


Happy Birthday @skilesare … i remember 45 … vaguely!

even i know java script is the default language of the web primarily by mistake. i would not choose it as such.

i think rust-lang is what we need to concentrate on in the future. -sorry

Rust is obviously very powerful, but we need more than one replica version for stability. I agree that JS leaves a ton to be desired, but I think it is a “good” choice simply because if the numbers of des it could stick with.

Eth2 has seven clients!

1 Like

160 ICP!

Since #3 and #4 are connected I’m going to release them together. I also adjusted the scale a bit to make it easier to get through the list. I still have the 80k at the top, but I would really love to do an ICCon in Austin. We need a hell of a benefactor though.

#3 Dfinity should mirror all system canisters with motoko reference implementation. If libraries are missing that would enable this they should build or fund the building of them.

This will drive dev growth and the ability to develop a broader group to review system canisters changes

Rust is apparently a great language. It also has memory management at its core and as a result, it is not going to take the world by storm. Not having a higher-level language that is performant and easy to start programming with will continue to be a hindrance to IC development. It will limit IC development to only the most skilled and most dedicated developers.

You Rust guys/girls are AWESOME, but there are not enough of you.

Tech like Demergent lab’s Azel and Kybra are great gateway drugs and we should find ways to promote and fund them. They get people into the IC and help them understand the concepts. There is likely a large chunk of the IC that can be built on those pieces of tech by your ‘more average’ dev, but at their core, they require running a virtual machine that limits their performance.

Since Motoko currently compiles straight to Wasm it has the ability to be as or more performant than rust. With deterministic time slicing and new garbage collection, it can be very competitive especially given the mental capacity advantage it has over rust.

Encouraging DFINITY to dog food motoko will make it a much stronger language. Recent examples like the BTC team forcing the growth of memory when actually trying to write a canister show the advantages of attempting to use your own language.

#4 Motoko should be generalized for other wasm platforms like filecoin’s vm.

Motoko does have a weakness in that it is an IC-only language. You have to be pretty sold out to the IC to commit to learning it and becoming an expert. An easy way to do this is to extend motoko beyond the IC.

Many new chains are using Wasm as an execution layer. These chains should be studied and we should apply motoko to those chains. We may need to lose some features like the async behavior that is specific to the IC, but many of the other features would map well to synchronous platforms. Many of the libraries we need built are synchronous and have other uses for them makes it more urgent to develop them.

It is also likely that those systems have asynchronous functionality that we can map to and help abstract asynchronous programming on those platforms.

I’d suggest starting with the filecoin VM as it is one of the biggest threats to the IC’s tech lead and bridging the devs focused there to the IC may be a way to maintain and demonstrate that tech advantage.



@skilesare, what about an option to pledge the ICP as a donation today without legally donating it until later? That could help a non-profit entity (“NPE”) plan for the future, while also preserving the very significant tax benefits of donations to coincide with a future sale of ICP triggering tax gains. In effect, this could give all parties (except the tax man!) the best of both worlds.

For example, if a typical(?) IC investor is convinced that ICP’s price will be somewhere north of $1,000 within 10 years, it clearly makes little sense to donate ICP at the current price of $4, especially with no large capital gains to offset this donation until 8+ years from now (given maximum dissolve delays). Could this be accomplished via one of the following workarounds (or something similar) to match future long-term capital gains with donation tax benefits, while still allowing for a current year donation pledge?

  1. Agreeing to a maximum control period by the donor, after which a pledged neuron would be formally transferred to the NPE’s neuron, perhaps enforceable via an NNS proposal agreed upon in advance by the donor and the NPE. I’m not sure if this would trigger the donation at the pledge date, though. An enforceable pledge could be deemed to be a complete surrender of the future benefits of the pledged asset to the NPE as of the date of the pledge.

  2. Allowing the donor to keep custody of the ICP via a hardware wallet but somehow requiring either the NPE’s approval or the NNS approval’s to make any changes to the pledged neuron. This could allow an NPE to enforce a public pledge (I think multi-sig. functionality over neurons would be required for this). In this scenario, the ICP would not be effectively donated until a much later date, since the ICP would simply be frozen until both can agree to whom it should be released and when (or the NNS becomes the tie-breaking vote based on the wording of the original pledge).

  3. As a potential alternative to multi-sig. functionality that does not yet exist, perhaps allow the NPE to control the pledged neuron, but allow only the donor to keep custody of the ICP via a hardware wallet, the latter of which would be required to make any changes to the neuron. I suspect that this could still allow the donor to bypass the mutual control over the staked ICP somehow and make staking changes (including selling the pledged ICP eventually for his or her personal benefit), but I’m not sure. Someone else should be able to confirm or refute the feasibility of this idea.

Are there any other thoughts out there about how to make a donation pledge enforceable without formally donating the ICP until a later date when accrued gains are much higher?

I’m in 100% agreement with everything stated here!

1 Like

There is a flag on neurons called non-profit that makes neurons transferable. I don’t think there is yet an NNS proposal to actually make that change and I think it has to be seeded that way during genesis. I’m sure an upgrade could change that.

The manage neuron topic lets you take maturity but not full control of the neuron. I don’t know of a good vehicle to do what you are suggesting and because canisters can’t control neurons very easily it is hard to pull off right now. But those are all good ideas that I’d love to see some workaround for.


So in all, we raised 160 ICP for ICDevs from four amazing donors! One other is trying to donate via the dedicate a neuron method but is being blocked by the fact that the NNS doesn’t let you manage that topic for yourself. I’m contemplating a bounty for someone to build a simple chrome extension that would inject the topic into the interface. I’m not sure if that is possible or not, but it would be a fun thing to figure out.

I’m going to go ahead an release Holho #5, but the rest are going to go into my hot take vault and you’ll have to wait until I can’t take the silence any more before I blast them into the social-verse.

Thanks for playing along!


Dfinity should fund a https://hardhat.org/ deployable evm that can be deployed to a canister yesterday. Start with a single-canister solution, scale from there.

Defi for free. Every solidity developer is able to deploy to the IC with a command line instruction. Chewing through cycles. Running your evm and your Dapp front end on the same infrastructure. I can go on and on about the advantages of having an evm. The one thing this isn’t? Profitable to the person that puts all the effort into developing it. It needs to be open-sourced and all the value will be captured by those implementing it. It needs to be funded by the IC community and we should have done it yesterday. The new t-ecdsa functionality makes this even more imperative as we now have easy ways to bridge across evm networks.


This one is brilliant.

Have you seen @blynn’s EVM demo?


Yes…I saw this months ago and was hopeful that it was leading to something, but I haven’t heard anything since. Is it open sourced? Might be a good starting place.

Wow. Thanks, anon! Someone just bumped us up to 500 ICP! That qualifies us for HOLHO #5.

This one is about governance and is probably my most lightly held opinion as I’m not convinced one or the other without too much conviction, but I have a good number of NNS scars and I regularly consider if this pattern is the best use of our time and if the community collateral damage is worth the process that has emerged(although it seems to have settled down significantly over the last few weeks).


The governance topic should be retired and the NNS should move toward rough consensus and running code.

We eventually have to decentralize the governance topics that actually make the IC go(blessing replicas, updating subnets, etc). As long as we have a perceived-effective “governance” topic that doesn’t actually do anything then we will be stuck engaging in fisticuffs on that topic. Let’s retire it or drop the weight to 0 and call it “non-binding resolutions.” People will be able to voice their opinion if they care enough and not vote without penalty if it isn’t important to them.

To encourage real replica voting we need to fund some orgs that can review replica changes and be followed in the topic. This takes real work. This shouldn’t be hard as a number of orgs with massive ICP holdings should be doing this for due diligence anyway. (For example…why aren’t node providers that will be installing the replicas doing their due diligence in public via a named neuron? I’d love to follow 5 or so of them on the bless replica topic as they have a significant amount to lose if a bad replica makes it through).

The other option is to do away with blessed replicas and let the nodes decide for themselves which replicas to run. This is eth/btc style decentralization and governance. If they don’t agree, they start slashing each ok there until agreement takes effect or a fork occurs. I think there is a lot of thinking about why this isn’t the choice that was made(concerning the consensus model), and it would be great to readdress and reaffirm those choices so that they are added to a larger consciousness.


The source:

$ git clone https://fxa77-fiaaa-aaaae-aaana-cai.raw.ic0.app/evm.git

It was a weekend hack that I abandoned because I grew tired of figuring out EVM details.

I’m afraid it’s a big mess. At the time, I thought it might be fun to try interleaving the stack and heap, as I had a hunch it would lead to fewer dirty pages for wasm VM to track. I regret the complexity caused by this premature optimization.


Holho: Motoko is a dead end. Should focus on something else like Rust + AssemblyScript. Otherwise agree.

What makes you think this? Ive had a much harder time with people bouncing off of rust.

I do think we need a higher level language, rust cant be the only option (hence the +), but more support wouldn’t hurt as it has a very strong ecosystem and bright future ahead of it.
I’m skeptical dfinity would commit to this, and even if they did, what are the odds of succeeding and others adopting it? I’m not :100: on this though. WASM still doesnt have a clear winner (other than rust).

Filecoin are also going to build an AssemblyScript SDK, as well as adding support for Agorics Secure Ecmascript (Which supports object capabilities and is super interesting btw). Motoko could be a tough sell I think.

1 Like

Awesome insight. I’ll dm you, would love to understand this better.

1 Like