Software engineer working in philanthropy/crypto. Former co-founder / Head of Tech, Effective Altruism Funds
SamDeere
Karma: 1,144
First, I’ll note that we’re actually planning to change this system (likely in the next week or two), so that instead of first seeing a default allocation, donors will choose their own allocation as the first step in the donation process.
To your question, the current EA Funds default allocation was chosen as an approximation of some combination of a) a representative split of the cause areas based on their relative interest across EA, and b) a guess at what we thought the underlying funding gaps in each cause area will likely to be. It’s definitely intended to be approximate, and is there partly as a guide to give an indication of how the slider allocation system works, rather than an allocation that we think everyone should choose.
Context: I help run EA Funds and am responsible for the user-facing side of things, including the website
We currently only require an email address to make deposits under $500k (so if you have an email address that doesn’t identify you then this would get you most of the way there). With larger donations we’d likely need to collect more information for KYC purposes.
The system as described above isn’t really set up to take deposits from smart contracts. The main issue is that EA Funds doesn’t take ‘unrestricted’ funding (as a normal charity would), and in order for us to allocate the donation correctly, we need a matching payment record from the donor (which you create when you go through the donation flow on the website) that tells us where the money should go. However, for one-off smart contract donations valued at >$10,000 we can probably work something out. Feel free to message crypto@effectivealtruism.org if you’d like to discuss further.
Update – winners have been drawn!
Thanks everyone who participated this year. The lotteries have been drawn and both had a winner!
$100k – Echo Nolan
$500k – Elizabeth Barnes
Congratulations both!
The grant payout reports are now up on the EA Funds site:
Long Term Future - $917,000.00
EA Community - $526,000.00
Note that the Grant Rationale text is basically the same for both as Nick has summarised his thinking in one document, but the payout totals reflect the amount disbursed from each fund
Thanks for this writeup. I’d also add that EA Funds accepts cryptocurrency donations, is tax-deductible in the US (501[c][3]), the UK, and the Netherlands, and doesn’t charge additional fees (fees are just whatever our exchange charges us, which is typically on the order of 0. 2% or lower). Donations can be made to any of our four Funds, or to a list of ~40 supported effective non-profits.
At the moment you need to get in touch with us directly to make donations, we support ~20 coin types, and our minimum donation size is $1,000+ or equivalent. However, we’re planning to roll out a new system (integrated with the normal donation form on our website) that supports over 120 coins and will have much lower minimums in the next month or so.
(Disclosure: I’m a co-founder of EA Funds)
The Centre for Effective Altruism UK (the legal entity behind EA Funds’ UK operations) is registered in the Netherlands as a tax-deductible charity.
When you get to the payment page you can select which country you’d like to donate in. To donate in a way that’s tax-deductible in the Netherlands, select ‘UK/NL’ as your country, and then optionally select EUR as your currency code. You can donate via credit card or SEPA transfer.
ETA: I’ve updated the relevant FAQ entry to make this clearer.
Yeah, I’d love to see this happen, both because I think that it’s good to pay people for their time, and also because of the incentives it creates. However, as Misha_Yagudin says, I don’t think financial constraints are the main bottleneck on getting good feedback or doing in-depth grant reviews, and time constraints are the bigger factor.
One thing I’ve been mulling over for some time is appointing full-time grantmakers to at least some of the Funds. This isn’t likely to be feasible in the near term (say, at least 6 months), and would depend a lot on how the product evolves, as well as funding constraints, but it’s definitely something we’ve considered.
A quick update to say that one of the features that seems to have prompted the initial post – the lack of the ability to manage recurring reported donations – has now been implemented. You can access it from the
Recurring Donationstab in the Pledge Dashboard sidebar:
I’ll first caveat by saying that I haven’t worked at either a typical startup or big tech company.
I think that there’s probably not a huge difference between CEA and a very early stage startup. I think that the most relevant dimension is just scale – currently we’re two devs working on a bunch of different projects, which means a high degree of autonomy and ownership over the code in a way that I expect is similar to a lot of small startups. We’re obviously a more mature org though, so we do have a lot of processes in place (CI, a dedicated Operations team etc) that you wouldn’t find at a really new startup. So, in some sense it’s the freedom and ownership of an early stage startup combined with the security and flexibility of an established org. It also means that there’s a lot of time spent on interacting with users (as opposed to just being siloed in your text editor), which I really like, partly because this is a great community and it’s really nice to talk to EAs who use your software, and partly because it helps you to get better at thinking about product development and making things that serve the needs of your constituency really well.
Another thing that’s a bit strange about CEA as a non-profit, and as an EA org, is that the approach to scaling is a bit different. In a for-profit startup, your aim is to grow as fast as humanly possible (at least, when you hit product-market fit). We’ve deliberately avoided that strategy (at least for now), in large part because it doesn’t seem prudent to scale something like the EA community as fast as possible, because scaling fast trades off pretty hard against the fidelity of your message and the existing culture of the community. This could obviously change in future, but historically it’s been part of our approach. This in turn means that the challenges are a lot about understanding how to build solid products that work for EAs, rather than how to run huge k8s deployments etc.
The money is kept aside as the first tranche of backstop for future donor lotteries – if someone wins, we’ll first draw from this pool of money to cover the pot, and then we’ll use the lottery guarantor’s money to cover any remainder.
I think that for most donors this can be disregarded. Even if the marginal use of your additional tax dollars is still pretty good (e.g. 10% as valuable as your best charitable option), you’re still better off donating to the charity. In extremis, it would imply that your best marginal donation option would be to voluntarily pay more tax, rather than donate.
While it seems in theory possible that the marginal dollar that your government spends is more effective than your best charitable donation option, I’d guess that in practice this is almost never the case, largely just because Your Dollar Goes Further Overseas, but also because your contribution to government revenue will be diffused between the many hundreds of programs that the government runs (some of which may be positive, like preventive health or basic research, others which may be pretty harmful, e.g. subsidies for industrial agriculture or maintaining nuclear arsenals).
The success of our factored evaluation experiments depends on Mosaic, the core web interface our experimenters use.
Is Mosaic an open-source technology that an applicant would be expected to have existing familiarity with, or an in-house piece of software? (The text of the job ad is a little ambiguous.) The term is unfortunately somewhat ungoogleable, due to confusion with the Mosaic web browser.
The NIST Beacon is back online. After consulting a number of people (and notwithstanding that we previously committed to not changing back), we’ve decided that it would in fact be better to revert to using the NIST beacon. I’ve edited the post text to reflect this, and emailed all lottery participants.
DAFs do make it much easier to donate appreciated stock, and this is good advice. However, if you want to make a donation of appreciated assests and you aren’t able to set up a DAF, EA Funds accepts donations of stock (in the US) and cryptocurrency (US, UK, and NL) for donations of more than $1000 (no promises that you won’t have to send a fax to your broker if you want to donate stock, but in general that hasn’t been the case for most of our donors who are donating from Vanguard etc).
The draw should to have the following properties:
The source of randomness needs to be generated independently from both CEA and all possible entrants
The resulting random number needs to be published publicly
The randomness needs to be generated at a specific, precommitted time in the future
The method for arriving at the final number should ideally be open to public inspection
This is because, if we generated the number ourselves, or used a private third-party, there’s no good guarantees against collusion. Entrants in the lottery could reasonably say ‘how do I know that the draw is fair?’, especially as the prize pool is large enough that it could incentivise cheating. The future precommitment is important because it guarantees that we can’t secretly know the number, and the specific timing is important because it means that we can’t just keep waiting for numbers to be generated until we see one that we like the look of.
The method proposed above means that anyone can see how we arrived at the final random number, because it takes a public number that we can’t possibly influence, and then hashes it using SHA256, which is well-verified, deterministic (i.e. anyone can run it on their own computer and check our working) and distributes the possible answers uniformly (so everyone has an equal chance of winning).
Typical lottery drawings have these properties too: live broadcast, studio audience (i.e. they are publicly verifiable), balls being mixed and then picked out of a machine (i.e. an easy-to-inspect, uniformly-distributed source of randomness that, because it is public, cannot be gamed by the people running the lottery).
Earthquakes have the nice property that their incidence follows a rough power law distribution (so you know approximately how regularly they’ll happen), but the specifics of the location, magnitude, depth or any other properties of any given future earthquake are entirely unpredictable. This means that we know that there will be a set of unpredictable (i.e. random) numbers generated by seismometers, but we (and anyone trying to game the lottery) have no way of knowing what they will be in advance.
(This is not actually that different to how your computer generates randomness — it uses small unpredictable events, like the very precise time between keystrokes, or tiny changes in mouse direction, to generate the entropy pool for generating random numbers locally. We’re just using the same technique, but allowing people to see into the entropy pool).
Other plausible sources of randomness we considered included the block hash of the first block mined after the draw date on the Bitcoin blockchain, and the numbers of a particular Powerball drawing.
TL;DR; – For Funds/GWWC, the frontends are React (via NextJS) running on Vercel (previously a React SPA running on Netlify). The backend is a bunch of Node.js microservices running on Heroku, connected to a Postgres DB (running on RDS), and wired together with RabbitMQ. We’ve migrated most things to TypeScript, but a lot of the backend is still JS. A lot of business logic is written in SQL/plpgSQL.
---
EA Funds and GWWC have been on the same platform since 2017, and share the same backend.
The frontend was a pretty standard React SPA written in JavaScript, but we’re currently in the process of deprecating this for a NextJS app written in Typescript (which has been a huge win in terms of productivity). EA Funds has been ported (compare the new with the old) already, and the incoming GWWC developer will be working with me on porting the existing SPA functionality to the same NextJS-based system. The new sites are in a Git monorepo managed with Yarn Workspaces, meaning that eventually all EA Funds + CEA sites will be able to share components/login architecture/backend connections etc.
Down the React rabbithole a bit: We connect to the backend using Apollo to manage GraphQL queries, we use Immer for immutable state management as needed (though we don’t use Redux or any other global state management). UI components are provided with Material-UI.
I used to use Netlify to host the EA Funds/GWWC frontend, but we’ve moved to Vercel for their first-class NextJS support.
The backend is a collection of quasi-microservices running on Heroku, all written as Node.js apps:
An Express web server that handles our GraphQL endpoint, as well as webhooks/callbacks for various integrations (e.g. Stripe payments).
The GraphQL endpoint is provided by Postgraphile, which is essentially a way of generating a GraphQL schema by reflecting over our Postgres DB. This means that we get to leverage the data structure, foreign key relationships, and type safety of the existing database for free in GraphQL. This approach means that a lot of business logic (especially around user-facing CRUD and reporting) are written directly in SQL, implemented as views and functions.
The services are connected by a RabbitMQ message bus. Database events (e.g. “db.payment.updated”) and webhook calls (e.g. from payment processors) are pushed onto the RabbitMQ bus , so that other services can react to these events. So, if a user inserts a new payment, the Payments service can communicate with the appropriate payment processor, and when the payment status is updated as succeeded, the Emails service can send out a receipt.
The Postgres DB is hosted on Amazon RDS.
---
In addition to EA Funds/GWWC, I’ve also helped set up a bunch of other sites used by CEA (e.g. EffectiveAltruism.org, EAGlobal.org, CentreForEffectiveAltruism.org, the GivingWhatWeCan.org homepage). Most of these are currently using the Metalsmith static site generator, which generates static HTML files that are served via Netlify. This setup has been fantastic for performance and reliability, but eventually these sites will be ported over to the NextJS monorepo for better maintainability.
---
In terms of pain points, it’s generally been a pretty solid system. The biggest challenges have been maintenance. E.g. we’ve migrated to NextJS, partly for the improved performance and DX, but also because the previous SPA was running an outdated version of React, and because of the way the boilerplate I used was architected, upgrading to a more modern version (which many packages now require) was more trouble than it was worth. Similarly, all the static sites have historically been hosted in their own repositories, which has meant that they all have slightly different ways of doing things, and improvements made to one don’t propagate to the others. Hence, the move to a monorepo, where we can share components/logic between sites. Also, the more I use TypeScript, the more I hate using vanilla JS, so I guess that’s something of a pain point in the parts of the backend that haven’t been migrated yet!
For EA Funds (and the pledge management parts of GWWC), that’s me. For the Forum it’s JP. We’re both devs first and foremost though, so we get a lot of input from other people (Aaron who manages the content side of the Forum, Luke Freeman who runs GWWC, Jonas who runs EA Funds, Ben West who manages the Forum team and who is a former tech startup CEO etc)
Thanks for the comments on this Marcus (+ Kyle and others elsewhere).
I certainly appreciate the concern, but I think it’s worth noting that any feedback effects are likely to be minor.
As Larks notes elsewhere, the scoring is quasi-logarithmic — to gain one extra point of voting power (i.e. to have your vote be able to count against that of a single extra brand-new user) is exponentially harder each time.
Assuming that it’s twice as hard to get from one ‘level’ to the next (meaning that each ‘level’ has half the number of users than the preceding one), the average ‘voting power’ across the whole of the forum is only 2 votes. Even if you make the assumption that people at the top of the distribution are proportionally more active on the forum (i.e. a person with 500,000 karma is 16 times as active as a new user), the average voting power is still only ≈3 votes.
Given a random distribution of viewpoints, this means that it would take the forum’s current highest-karma users (≈5,000 karma) 30-50 times as much engagement in the forum to get from their current position to the maximum level. Given that those current karma levels have been accrued over a period of several years, this would entail an extreme step-change in the way people use the forum.
(Obviously this toy model makes some simplifying assumptions, but these shouldn’t change the underlying point, which is that logarithmic growth is slooooooow, and that the difference between a logarithmically-weighted system and the counterfactual 1-point system is minor.)
This means that the extra voting power is a fairly light thumb on the scale. It means that community members who have earned a reputation for consistently providing thoughtful, interesting content can have a slightly greater chance of influencing the ordering of top posts. But the effect is going to be swamped if only a few newer users disagree with that perspective.
The emphasis on can in the preceding sentence is because people shouldn’t be using strong upvotes as their default voting mechanism — the normal-upvote variance will be even lower. However, if we thought this system was truly open to abuse, a very simple way we could mitigate this is to limit the number of strong upvotes you can make in a given period of time.
There’s an intersection here with the community norms we uphold. The EA Forum isn’t supposed to be a place where you unreflectively pursue your viewpoint, or about ‘winning’ a debate; it’s a place to learn, coordinate, exchange ideas, and change your mind about things. To that end, we should be clear that upvotes aren’t meant to signal simple agreement with a viewpoint. I’d expect people to upvote things they disagree with but which are thoughtful and interesting etc. I don’t think for a second that there won’t be some bias towards just upvoting people who agree with you, but I’m hoping that as a community we can ensure that other things will be more influential, like thoughtfulness, usefulness, reasonableness etc.
Finally, I’d also say that the karma system is just one part of the way that posts are made visible. If a particular minority view is underrepresented, but someone writes a thoughtful post in favour of that view, then the moderation team can always promote it to the front page. Whether this seems good to you obviously depends on your faith in the moderation team, but again, given that our community is built on notions like viewpoint diversity and epistemic humility, then the mods should be upholding these norms too.
Fund managers are appointed by CEA on the recommendation of the Fund Committee (in the case of the Meta Fund, my understanding is that currently all committee members have input on the decision, with equally-weighted votes, though this is not the case on all Fund teams). My understanding from conversations with members of the Meta Fund team is that the last recruitment round considered candidates from several locations, with an emphasis on trying to find someone from the Bay Area. At least two promising candidates (both based in the Bay) were approached, but were ultimately unable to take the position. While the appointee (Peter McIntyre) does live in London, he’s originally from Australia, and has recently moved back from living in the Bay, and maintains strong connections there.
As an aside, I’d note that the team is somewhat more geographically diverse than is being presented here. While the plurality of the team currently lives in London, with a member in Hong Kong and an advisor in the Bay, they also come from five different countries, and as far as I know most have lived in several different cities.
I’m happy to forward nominations for Fund managers (for any of the Funds) on to their respective Chairs. The best thing to do is send me an email at sam[at]centreforeffectivealtruism[dot]org.