Rust and Blockchain Engineer

We’re a tight, passionate team who moves fast and gets things done. We started Fractal in 2017, and our first product was Fractal Launchpad — a crowdfunding platform where blockchain projects such as the Ocean Protocol raised funds from the community.

Fractal ID, our current product, is a federated identity system (think “log in with Facebook”, but with verified users). It collects and verifies user identities according to the compliance needs of our clients (blockchain fintechs). Because these identities are reusable, we deliver fast frustration-free onboarding for users and high conversion rates for clients. We also help users create decentralized identities on Ethereum and hold their credentials in our Fractal Wallet product.

We’ve now started to build the Fractal Protocol on Substrate. It is an open source protocol designed to rebalance the online advertising market by providing safe infrastructure for incentivized data provisioning and consumption. The ad market used to fund a free and open Web — critical for democracy and inclusion — but has fallen into the hands of a rent-seeking oligopoly. We believe we can build a new equilibrium that respects user privacy, protects advertisers from fraud and rewards content creators. This is because we finally have the technology to get it done. Blockchain provides a trustless, shared source of truth for mechanism design. Zero-knowledge proofs and differential privacy help keep users safe. Decentralized identity and verifiable credentials brings people self-sovereignty over their own data.

The following attributes are a requirement for any candidate:

1. You are comfortable with Rust.
2. You care about engineering quality, and make our system better by being there, beyond just adding features.
3. You are familiar with general workings of blockchains and decentralized protocols. What problems do blockchains solve? What problems do they create? What kinds of things do we need to think about when developing decentralized things instead of something where we control the machines?
4. You are able to self-direct: an intelligent person who can follow your interest in what should be solved without us having to manage your day-to-day.
5. You hold strong opinions loosely. Part of the benefit of multiple engineers is having different opinions/experiences. You share your opinion when you disagree with ours, because we’ll end up somewhere better, at least with one of us having a better understanding of what we differed on.
6. You attacks problems, not people.
7. You have experience in solving difficult problems. A lot of engineers get by doing basic feature development and never having to solve challenging problems. We need to know you can solve problems when there isn’t a tutorial or Stack Overflow answer.
8. You positively contribute to team functioning, and value working with others instead of resenting it.
9. You keep up with programming best practices. The field of software engineering is still new, so we are constantly discovering new ways of doing things better. We want someone who isn’t stuck in how they did things 10 years ago.

These are nice to have:

1. Familiarity with peer-to-peer networking.
2. Experience building things with Substrate or other blockchain systems.
3. Experience building front-end UI, preferably with JS, preferably with Angular.
4. Experience with Agile software development.
5. Familiarity with test driven development.

These are not important:

1. Years working with X. Their confidence and ability to use X is important, it’s just that sometimes it doesn’t matter how long it’s been, though that usually correlates.
2. Education credentials are overrated.
3. Domain expertise. The domain expertise we want is just general ideas about how blockchains work (why “block” and why “chain”, also how “chain”). We don’t need someone who has spent their last 5 years doing blockchain startups. A good candidate can learn what’s necessary.
4. Tools you use. As long as you can learn Git/GitHub and contribute quality code to the repository, we don’t care how you make it.

Your day-to-day will be mostly some combination of:

1. Working on user stories from the backlog
2. Performing code reviews
3. Working on design proposals
4. Giving feedback on design proposals

Regularly, usually weekly, we will as a team:

1. Estimate user stories
2. Demo our work to relevant stakeholders
3. Run a retrospective to improve our efficacy

You’re welcome to, but not expected to, participate in any of:

1. Planning: writing user stories, influencing priorities, deciding on features
2. Community contributions: extracting pieces of our primary work to be reused by others, contributing to projects we use
3. Business development: investigating new potential use cases, designing features to facilitate new use cases