Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
Heya Gitcoiners & Gitcoinerettes! They say that July is the warmest month of the year (location depending), and we’re definitely getting ready fo…
Howdy, Gitcoiners! This month we’re running hackathons, we launched Grants Round 6 (which we just tweaked big time btw), we’re building, we’re improv…
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
# Overview / Motivation
We shouldn't use any persistent parts in our unit tests
# The Task
Currently, we use database.NewLevelDbStore to create the DB for meshDB in the unit tests,
We should use only MemoryDB for unit tests.
Replace all occurrences of database.NewLevelDbStore in out unit tests to MemDatabase
# Time Estimation
# Implementation Notes
check out block_listener_test.go
# Contribution Guidelines
Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who have'nt introduced themselves on our Gitter [dev channel](https://gitter.im/spacemesh-os/Lobby)
1. Introduce yourself on go-spacemesh [dev chat channel](https://gitter.im/spacemesh-os/Lobby) - ask our team any question you may have about this task
2. Fork branch `develop` to your own repo and work in your repo
3. You must document all methods, enums and types with [godoc comments](https://blog.golang.org/godoc-documenting-go-code)
4. You must write go unit tests for all types and methods when submitting a component, and integration tests if you submit a feature
5. When ready for code review, submit a PR from your repo back to branch `develop`
6. Attach relevant issue to PR