00/Test project
A deliberately narrow slice of the real problem: two players, one heads-up hand, no trusted dealer, settled on-chain. Small enough to finish in ten days. Hard enough that finishing it tells us almost everything we need to know.
Parameters
Ten days is real work, so there is a stipend on submission whether or not we make an offer. The brief is also deliberately narrowed to be representative but useless to us — heads-up only, no table server, no seats, no side pots.
We claim no ownership over anything you submit. Publish it, reuse it in another application, put it on your GitHub — it is your code. All we ask is that you do not publish our specification alongside it.
01/The brief
Two processes, no shared trusted party, a real deck, a real betting round, and real (testnet) money moving at the end. Everything below is the complete deliverable set.
Implement a two-party commutative-encryption shuffle in TypeScript. Each party encrypts the deck under its own key, the deck is permuted, and cards are decrypted only for their intended recipient. Neither party may learn a card that has not been dealt to them.
A LIGO contract on Shadownet that escrows two buy-ins, accepts the agreed final state signed by both parties, and pays out. Include a unilateral timeout path so a player abandoned mid-hand can still recover funds.
A seven-card evaluator that returns a total ordering over hands. Correctness matters far more than speed, but tell us the complexity you achieved and why you chose that approach.
A CLI or test harness that plays a full heads-up hand end to end between two processes — shuffle, deal, a betting round, showdown, on-chain settlement — with no human input.
Two pages. How would a hostile player cheat your implementation, which of those attacks your code already prevents, and which you would address before real money touched it.
Optional and deliberately open. If you think the specification above is wrong somewhere, ignore it and show us the better version — but say why in the write-up.
02/Definition of done
If this sequence completes on a clean clone with only the README to guide us, your submission has cleared the bar. Everything after that is a question of quality rather than completion.
Two processes should negotiate a shuffle, deal two hole cards each, run a single betting round, reveal the board, determine a winner, and have the Shadownet contract pay out — with no human in the loop and no party ever able to read a card it should not see.
$ npm install
$ npm run deploy:shadownet
$ npm run play:headsup
✓ deck shuffled — 52 cards, mutually encrypted
✓ hole cards dealt — 2 per player
✓ betting round complete
✓ showdown — player_b wins with a flush
✓ settled — op hash oo7Kx…9Qm2
03/Assessment
Published in advance, because a hidden rubric tests your ability to guess rather than your ability to engineer.
Does the shuffle actually hold its security property, or does it merely look like it does? We will read this against the literature.
Entrypoint design, failure paths, gas sanity, and whether the timeout path can be abused by the party who invokes it.
What you chose to build properly, what you chose to stub, and whether you can articulate the difference.
Test vectors for the evaluator, adversarial cases for the protocol, and a harness someone else can actually run.
The write-up and the README. Can a new engineer clone this and be productive in an hour?
Note the weighting: protocol correctness and contract quality together are 55%. A submission with an elegant UI and an unsound shuffle scores far worse than an ugly CLI that gets the cryptography right.
04/Ground rules
05/Support
Ready
The full brief, the specification, the Shadownet endpoint and funded test accounts go out within one business day of the technical conversation. The clock starts when you tell us you are ready — not when we send it.
Applying for one of the two design seats instead? There is a separate paid commission with the same window, the same stipend and the same promise that we do not ship it — the design commission.