Lantern Ventures is a London-based proprietary trading firm specialising in cryptocurrencies. We use technologies developed in-house to identify and execute on trading opportunities arising in cryptocurrency markets worldwide. Lantern Ventures is a strongly mission-driven organisation, donating 50% of firm profits to highly effective charities; applicants with an interest in this mission will be favourably considered.
Skills/Experience:
4+ years back-end experience using Haskell or a mix of Haskell and other FP languages professionally or open-source
2+ years front-end experience using React/Typescript
Proficiency with SQL strongly preferred
Experience working with heterogeneous time series data, especially financial data, is a plus
Experience with one cloud provider AWS/GCP/Azure, Infrastructure as code, Docker is a plus
Experience with Redis is a plus
Strong written and verbal communication skills in English required
Experience working in small teams in a startup-like environment and building and shipping products that are critical to business success is a plus (figuring out what is required, how to build it, how to fix it, iterate on it)
What's the logic here? Expected value is the same in all cases right?
Yep, the expected value remains the same, it's just a suggestion to encourage people make an entry that has a non-negligible chance of winning. As we say in the preceding sentence, there's no minimum entry size, so if you want to enter with a very long shot, that's entirely possible.
Can you share who the guarantor is this year?
As in previous years, the lottery is guaranteed by funds held at CEA on behalf of Carl Shulman.
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 [email protected] if you'd like to discuss further.
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.
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).
For EA Funds this is something that we’re planning to do very soon. It’s something that’s always on the backburner (as shipping features always tends to take priority), but now that there’s a new website that has much better global control of component styling, this is something where I think we can get some easy wins.
Not really (we’ve sporadically used Personas in the past, but not very systematically), but I’ve actually just been doing more reading on this. I expect that (at least for EA Funds) Jobs-to-Be-Done will be a big part of our user research project going forward.
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!
Thanks for this - both should be fixed
Senior Full-stack Haskell Engineer @ Lantern Ventures
Location: London, UK, Flexible working (minimum 2 days a week from the office - fully remote can be considered)
Salary: £90k - 130k (depending on experience) + discretionary bonus
Hours: Full time
Contract type: Permanent with a 3 month probation period
Closing date: 30th of April 2024
Apply NowAbout Lantern Ventures:
Lantern Ventures is a London-based proprietary trading firm specialising in cryptocurrencies. We use technologies developed in-house to identify and execute on trading opportunities arising in cryptocurrency markets worldwide. Lantern Ventures is a strongly mission-driven organisation, donating 50% of firm profits to highly effective charities; applicants with an interest in this mission will be favourably considered.
Skills/Experience:
We do, although it looks like it's not showing on the site. I'm just fixing the issue, will update when it's there.
Yep, the expected value remains the same, it's just a suggestion to encourage people make an entry that has a non-negligible chance of winning. As we say in the preceding sentence, there's no minimum entry size, so if you want to enter with a very long shot, that's entirely possible.
As in previous years, the lottery is guaranteed by funds held at CEA on behalf of Carl Shulman.
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 [email protected] if you'd like to discuss further.
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)
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).
For EA Funds this is something that we’re planning to do very soon. It’s something that’s always on the backburner (as shipping features always tends to take priority), but now that there’s a new website that has much better global control of component styling, this is something where I think we can get some easy wins.
Not really (we’ve sporadically used Personas in the past, but not very systematically), but I’ve actually just been doing more reading on this. I expect that (at least for EA Funds) Jobs-to-Be-Done will be a big part of our user research project going forward.
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:
---
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!