Backend Engineer (Rust, blockchain)

01About the role

Most of what this product has to get right happens on the server. A quote has to be honest about every cost before anyone signs; a swap that crosses two chains has to reach its end whether or not the tab that started it is still open; and the record of what happened has to be good enough to pay people from. The routing and the swap path are built and run end to end. The launch is ahead of us, and so is everything that has to hold once real money is moving. That is the work: Rust and Postgres, with the chain and its providers on the other side of the wire. It is not a research role. The specification and the threat model are written; what is missing is somebody to build it and stay with it in production.

02What you will do

• Own the execution path after a signature: a swap becomes an operation with one current state, followed to completion by a worker rather than by the page that started it.
• Build the event ledger the points and the airdrop are paid from. It is append-only and enforced by database grants rather than by the code remembering not to update.
• Keep the money rules on the server: slippage enforced rather than suggested, every cost its own line, and a minimum the user is shown that matches the one the chain enforces.
• Integrate routing and RPC providers with a primary and a failover, and treat every one of them as a hostile network. A poisoned RPC layer cost somebody 292 million dollars this year.
• Keep one OpenAPI document as the source both clients are generated from, so a field cannot come to mean two things in two apps.
• Carry your own work to production on Kubernetes: the migration, the pipeline, and the alert that wakes somebody.

02Good fit if you have

• Rust in production with Postgres underneath it: something that ran, that you were responsible for, and that had users.
• Comfort with async services under real failure: retries that are safe to repeat, work that survives a restart, and state you can reconstruct.
• Enough on-chain literacy to know what a signature commits a user to, and why an address is not a lowercase string.
• The instinct to write the decision down before building it, with what you rejected and what would change your mind.

03Nice to have

• Something you have shipped on-chain: a wallet, a swap, a bridge or aggregator integration.
• SQL beyond an ORM. You have written the migration that could not be rolled back and planned for it.
• TypeScript and React, enough to follow a value from the API to the screen it is shown on.
• Kubernetes, infrastructure as code, or a CI pipeline you have made trustworthy.

04Example projects

• Follow a cross-chain swap to its end after the tab that started it is closed, and tell the person it landed.
• Make the ledger refuse an update at the database level, then prove it refuses one in a test.
• Put a second RPC provider behind the first and decide, in code, when to stop trusting the first.
• Fix an address comparison that folds case on a path that is not EVM-only, a class of bug that merges two distinct accounts.
• Take a quote path that hides a fee in the rate and give every cost its own line.

05What we offer

• B2B, in PLN or the USDC equivalent. Monthly invoice, paid within seven days.
• Fully remote, from anywhere. Async by default, CET.
• A company laptop and hardware security keys, provided and configured.
• A written specification and threat model, and a decision when you flag that you need one.

06How to apply

1. 1.What you have built in Rust, what it was responsible for, and what broke in it.
2. 2.A schema or a migration you are proud of, and why it is shaped that way.
3. 3.One paragraph: a decision you made that was hard to reverse, and what you wrote down before you made it.
4. 4.Your availability, and your rate if it sits outside the range above.

The third point is the one we actually read.