Listening to a recent episode of the Solarpunk Presents podcast reminded me the importance of consistently calling out cryptocurrency as a wasteful scam. The podcast hosts fail to do that, and because bad actors will continue to try to push crypto, we must condemn it with equal persistence.
Solarpunks must be skeptical of anyone saying it’s important to buy something, like a Tesla, or buy in, with cryptocurrency. Capitalists want nothing more than to co-opt radical movements, neutralizing them, to sell products.
People shilling crypto will tell you it decentralizes power. So that’s a lie, but solarpunks who believe it may be fooled into investing in this Ponzi scheme that burns more energy than some countries. Crypto will centralize power in billionaires, increasing their wealth and decreasing their accountability. That’s why Space Karen Elon Musk pushes crypto. The freer the market, the faster it devolves to monopoly. Rather than decentralizing anything, crypto would steer us toward a Bladerunner dystopia with its all-powerful Tyrell corporation.
Promoting crypto on a solarpunk podcast would be unforgivable. That’s not quite what happens on S5E1 “Let’s Talk Tech.” The hosts seem to understand crypto has no part in a solarpunk future or its prefigurative present. But they don’t come out and say that, adopting a tone of impartiality. At best, I would call this disingenuous. And it reeks of the both-sides-ism that corporate media used to paralyze climate action discourse for decades.
Crypto is not “appropriate tech,” and discussing it without any clarity is inappropriate.
Update for episode 5.3: In a case of hyper hypocrisy, they caution against accepting superficial solutions---things that appear utopian but really reinforce inequality and accelerate the climate crisis---while doing exactly that by talking up cryptocurrency.
I would personally think most things like voting be off chain so you can do things like secret ballots more easily, but also just the cost. The use would be use the on-chain contracts to establish the org, governance and the off chain systems to establish an external root of trust. Its was also a growing development to tie the DAO to a matching legal structure so that things like taxes but also state enforcement of contracts. This means you can issue tokens with legal stipulations like (one token per member).
I agree that trying to use this to solve all problems of building an organization is fool hardy. In the same way I don't think worker and community coops solve everything (but I do support them!)
They don't solve everything, but the evidence does seem to indicate they are an objectively better way to operate, with virtually no downsides compared to regular corporate structures.
The problem, basically, is that everything you can do with a DAO can be done just as easily without one. Working out the legal particulars of contracts is still a job for lawyers, for example. That job doesn't get better, easier or cheaper because you now have to pay a lawyer and a programmer. It's all just added complexity for the sake of added complexity.
I don't agree, its the same benifit expressed in the idea of policy as code for encoding security policy of IT systems to be turn into reusable and programtically accessible checks.
You could have a team of cyber professionals that know compliance standards and deeper knowledge answering every question and reviewing every deployment or you could add some relevant programming skills to that team and catch known things automatically.
This seems like a pretty big barrier for adoption, not to mention an added layer of bureaucracy. If every single deployment has to be reviewed, you're creating a new bottleneck and adding a centralizing factor. Catching known things automatically sounds overly optimistic, considering automated testing for other programs still doesn't catch every bug.
Honestly, I'm really struggling to imagine scenarios that are either only possible with DAO's, or where they are so massively better than just a normal voting system. If organizations remain small and federated, and if there are no owner/employee dynamics (replaced with coops), its likely that voting fraud would likely be extremely minimized, since everything could just be transparent to begin with.
It just feels like the equivalent of having smart-lights in your home. It's a little more covenant than getting up and pressing the switch, but now I have an operating system, program, and wifi protocol inserted between me and turning a lightbulb on, introducing many points of potential failure and potential security implications for the most minor of conveniences.
Can you give me some examples of things that have been a big problem for an organization that you've been involved with that would definitely be solved by DAOs?
So a project I would like to set up is using a DAO to manage the funding account of and the account of a cloud resource.
So that the a democratic vote can be held on the public record for how it is configured, as opposed to the standard sys admin model of a single owner and manual adding more people to it with powers to delete other admins.
The problem what ever the first system is root of trust, so the basis being an established network like ETH would make it necessary for a much larger consensus to chain that initial config with the members of the DAOs approval.
I think this is more important at larger scales, which while smaller is more agile being able to scale teams and orgs up is just needed for things that benifit from economies of scale.
You want to review things before deployment anyways. At home on low risk systems with no major threats its not a big deal, but for larger more threatened or more critical systems you have to introduce more checks, and reviews, automated or otherwise.
You wouldn't, for example, a flight control tower to just accept updates from anywhere. Codifying checks, either functional tests, or compliance checks will only ever establish a baseline, catching the common and understood issues.
In trying to understand the upside of the DAO in that use case:
I'll start with number 2. For sure there is, for example the Lemmy instance I'm using, I can say it supports Lemmy clients and can talk to other Lemmy instances but I have no way of know what the state of the actual running back end is. It could be compromised, exiflitrating data, puppeting my account, etc whatever it wants to do. If the instance admin wanted to they can configure however they want and my only option is to leave.
They could do a straw poll but it's ultimately at their discretion. A straw poll puts the users as counsol too the ones in charge. It does hold anyone accountable.
The funding streamlining would come from the fact that the DAO can own wallets and make periodic payments based on what was voted on or create multisig wallets for sub teams to manage their own budgets given to them by the DAO. Compare this a traditional a setup where to schedule payments that group agreed upon, where a vote would have to be held, then the decision sent to accounting to then sent to a bank to then sent to the target wallet. Each one of those hand off introducing the possibility of confusion or obfuscation.
I saved the first one for last because I feel like I know the least on that one. There is docs on how to do it https://ethereum.org/en/dao/ and I know it means that a token becomes associated with a wallet on the chain, but the exact methods that a DAO might actually do that is something I haven't done and I know it can be done in different ways.
I'm no expert on servers, so correct me if I'm wrong here, but I'm assuming the blockchain would essentially just list the status of various administrative things on the system, like how the firewall is set up or what ports are open, and users would be able to vote on changing individual settings?
Surely that's only within certain limitations? Like if your users collectively voted with the DAO to host illegal material, and that was automatically put through, the server owner would ultimately be responsible for continuing to host that material, and presumably would take action to stop it regardless of the DAO.
So the owner ultimately still has to monitor what the users are doing on the DAO, and intervening if need be.
So a user would need to be tech-savvy enough to set up an account with an exchange to convert their real money into crypto and send it to the correct wallet (which I suspect is more prone to error than using Librapay).
I feel like all of those processes happening via crypto would, if anything, increase obfuscation. I guess theoretically, it does remove the steps of the sysadmin needing to move crypto between wallets, but if the end-goal of the vote is to send money somewhere that's not on the chain, wouldn't that mean the owner of the managed account would need to manually convert the crypto out of an exchange and into a regular bank account to then be sent to the final destination account?
With such widespread fraud and history of insecurities in crypto exchanges, I feel like the admin would be trading a minor inconvenience of not needing to do some minor administrative work in exchange for much bigger potential headaches.
For the simplest case you just have your system pull down config data from the blockchain as you would any DB and configure its self based on that data (because of costs probably something like which private chain to pull from or which got repo to look for configs from, and from there deploy the system with your standard gitops workflow for configuring cloud infrastructure, os, platform (e.g. k8s), and app configs.)
You also can use what are called oracle services if hitting API from the smart contracts themselves is seen as useful.
Google cloud also support ETH payments so that simplifies that some. Other hosting services exist too, but GCP a pretty mature platform.
It doesn't NEED to be as complicated of an IT system, just saying it can scale handled to more complicated.
I would think something like bitpay would be a good choice. Have the DAO controlled wallet put eth via smart contract to a bitpay address that is setup to LLC's account (or whatever legal entity owns the bank account), and from there do your normal fiat payments (this too could be controlled by something like invoice ninja that's configuration was defined on-chain).
All this to say you have to:
All of this to enable day two ops for things like: increase spend of cloud service vote increases, wallet is sent more funds, cloud setting config changed to support the higher spend, etc
All automated. With the voting mechanism making it possible to review the financial changes and system changes as a collective in one swoop, and then after that executing potentially without human hand offs.