Celo Mondo is a DApp for participating in staking and governance on Celo.
Earn rewards by locking & staking your CELO tokens. Help decide Celo's destiny by casting your vote in on-chain governance proposals.
For information about how Celo's Proof-of-Stake protocol works, or other aspects of the Celo blockchain, see the official Celo Documentation
For support, you can file an issue on this repository or join the Celo Discord
To run Celo Mondo against alfajores network set NEXT_PUBLIC_RPC_URL
env variable to alfajores
.
To run Celo Mondo against any other network (such as your local testnet) set NEXT_PUBLIC_RPC_URL
env variable to http://<your-rpc-url>
.
- Install:
yarn
- Setup:
yarn prepare
- Run locally:
yarn dev
- the
/governance
pages are powered by a postgresql database that needs to be setup, there's a docker file for your convenience as well as a (hopefully not too dated) data dump in./db_dump.sql
- restore with
cat ./db_dump.sql | docker exec -i <your-db-container> psql -U postgres
- make sure your .env has a valid
POSTGRES_URL
variable
- the
- Test locally:
yarn test
For more information about the architecture and internals of this app, see DEVELOPER.md.
This section is a short explanation for the governance fetching and displaying. For some context, celo-mondo didn't have a backend part for a long time and fully relied on three data sources: celo blockchain, celoscan events API, and the github repository celo-org/governance. This meant that all merging and data fetching had to happen at runtime in the front-end, per client. Now, since the introduction of the backend we set-up a flow to make the front-end a bit simpler.
Events are indexed in the events
table (for redundancy, data is fetched from both webhooks and a github action cronjob just in case).
When a new events is received, we can decode it and update the proposals
table according the event to have an always up to date table that the each front-end client can fetch without further data manipulation. See src/app/api/webhooks/multibaas/route.ts
to see the webhook and the function calls.
There's a small schema explaining each table in more details here: