DamageBDD Contractor Development Process
1. Purpose
This page defines a lightweight, self-managed workflow for contractors contributing to DamageBDD. It is intentionally simple. You do not need to understand Behavior-Driven Development (BDD) to start. You only need a GitHub account and a BTC or Lightning wallet.
Over time, you will naturally learn BDD because every task in the project is verified using it.
This process is:
- Non-custodial
- Non-employment
- Non-investment
- Globally permissionless
- Fully auditable via GitHub
2. Communication Rule
All communication happens via GitHub Issues. No email, no DMs, no meetings unless absolutely required.
Each issue represents:
2.0.1. The scope
2.0.2. The expected output
2.0.3. The acceptance criteria
2.0.4. The payout
2.0.5. The payment method (one-off BTC address or Lightning invoice)
This protects both sides and removes management overhead.
3. Workflow Overview
- Find an issue labelled
openorhelp-wanted. - Comment “/claim” if you want to work on it.
- Maintainer assigns the issue to you.
- Open a branch, build the solution, and push a PR referencing the issue.
- Maintainer reviews & merges.
- You get paid in BTC (on-chain or Lightning) to a one-off address or invoice you provide inside the PR.
That’s all.
BDD only becomes relevant later when the issue itself contains a feature file you must implement.
4. Step-By-Step Process
4.1. 1. Pick an Issue**
Go to the repository’s Issues page. Look for:
4.1.1. bounty
4.1.2. open
4.1.3. help-wanted
4.1.4. easy, medium, or advanced
Each issue already contains:
4.1.5. A short description
4.1.6. A task breakdown
4.1.7. Payout amount listed in sats
4.1.8. Expected “definition of done”
4.1.9. (Optional) BDD feature to implement
If you need clarification, ask inside the issue, not privately.
4.2. 2. Claiming Work**
Comment on the issue:
/claim I agree to deliver this task for the quoted sats. Work will begin now.
The maintainer will assign you. This avoids schedule / responsibility confusion.
—
4.3. 3. Working on the Task**
Create a branch in your fork:
git checkout -b feat/<short-task-id>
Implement the solution.
If the issue includes BDD, just follow it as best as you can. If you don’t know how yet—don’t worry. The maintainer will help clean it up. The key is: deliver the thing.
—
4.4. 4. Submit a Pull Request**
Open a PR with this exact structure:
### Summary Fixes issue #<id> ### Verification Describe: * What you changed * How you tested it (manual is OK initially) * Any output or logs ### Payout Payment Rail: BTC (on-chain) | Lightning One-Off BTC Address or BOLT11 Lightning Invoice: <insert your one-off address or invoice here> Amount: <as listed in issue> I confirm: - This is a fresh, one-time payout destination. - I control this wallet. - This is a non-custodial wallet. - This payment is for completed work only. ### Notes Anything extra we should know.
This is your invoice. There is no extra emailing or admin.
—
4.5. 5. Review & Merge**
Maintainer reviews your PR. If changes are needed, they are requested inside GitHub. Once approved and merged, you mark the issue as:
/ready-for-payment
—
4.6. 6. Payment**
You are paid in BTC (on-chain or Lightning) to your quoted address or Lightning invoice. This is finalised inside the Issue thread so the record is permanent.
For Lightning:
- Only BOLT11 invoices are accepted.
- Invoices must be non-custodial.
- Expired invoices require resubmission.
- Lightning payments are final.
DAMAGE token liquidity, pricing, or conversions are not your concern. The treasury handles that.
—
5. Payment & Wallet Rules (Strict)
- Never reuse payout addresses. Always generate a fresh one.
- Never submit exchange deposit addresses.
- Never submit custodial Lightning invoices.
- One work item = one payout destination.
- All payout details must live in the PR.
- No payout details via DM, email, or chat.
Failure to follow these rules may void payout eligibility for security reasons.
—
6. Legal & Relationship Clarification
By participating in this workflow, you acknowledge:
- You are an independent contractor, not an employee.
- This is not an investment, not revenue sharing, and not equity.
- Payments are final compensation for completed work only.
- You are responsible for your own tax, reporting, and compliance.
- DamageBDD does not custody funds on your behalf.
—
7. Best Practices for Contractors
- Never reuse BTC addresses or Lightning invoices.
- Put all questions inside the issue.
- Keep branches small—one issue = one PR.
- Don’t wait for permission. If it’s assigned to you, build.
- If you’re stuck, comment in the issue.
Over time you will see that nearly every problem in DamageBDD ends with: write the behaviour in Gherkin and let the platform verify it.
You’ll naturally transition into BDD-driven development without being forced.
—
8. Why This Workflow Works
- Maintainer doesn’t micro-manage.
- Contractors control their own time.
- GitHub holds the full audit trail.
- Issues → PR → Merge → Pay.
- Scaling team ≠ scaling overhead.
- No off-platform chatter.
- No dependency on contractors learning BDD on day one.
- Lightning enables instant, global, non-custodial micro-payouts.
Everything else—BDD pipelines, DAMAGE token, Aeternity receipts, Lightning settlement—runs behind the scenes.
—
9. One Sentence Summary
Do the work, open a PR, submit a one-off BTC address or Lightning invoice, get paid. GitHub is the contract.