Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

feat(reservations): escrow-backed reservations

Ouverte
  • Quelque chose ne va pas ?
#9 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
backend, databases

Piste de recherche

Read quantum_backend_v2/reservations/service.py and reservations/models.py to understand the reservation transitions, then inspect the credit ledger work in issue #3 and recovery in runtime/recovery.py. Define and test how each terminal state produces exactly one ledger outcome, how holds appear in the reservation API response, and how restart recovery restores or releases them. The issue calls for state-machine tests across transitions and recovery; on-chain escrow is a separate optional phase.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

chain-integration enhancement payments tier-2

Summary

Tie the reservation state machine to funds: lock on COMMITTED, release on EXECUTED, refund on EXPIRED or CANCELED.

Motivation

Reservations already model intent to use a node. Backing them with a hold makes no-shows and cancellations costly and protects workers.

Current state in this repo

  • quantum_backend_v2/reservations/service.py and reservations/models.py implement REQUESTED -> PREPARED -> COMMITTED -> EXECUTED/EXPIRED/CANCELED.

Proposal

  • Phase 1: ledger-only holds using the credit ledger (#3).
  • Phase 2 (optional, separate PR): on-chain escrow on a registry EVM chain, reusing the Aave-based escrow pattern from proposals or a minimal escrow contract.
  • Define timeouts so holds cannot be stuck: expiry always results in release or refund.

Acceptance criteria

  • Every terminal reservation state results in exactly one ledger outcome (capture, release or refund).
  • Holds are visible on the reservation API response.
  • Crash recovery (runtime/recovery.py) restores or releases holds.

Out of scope

  • Writing production-audited smart contracts; any contract in Phase 2 stays testnet-only until audited.

Dependencies

  • #3
  • #8

Testing plan

  • State-machine tests covering every transition and restart recovery.

Part of ##1. Ground rules for all issues in this roadmap are listed there (testnet-first, no secrets in the repo, chain logic behind the registry, tests and docs with every PR).

Langage dominant
Python
Étoiles
2
Forks
4
Merge moyen
6 h 13 min
PR mergées (30 j)
20

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de QMeshPy/distributed-quantum

Toutes les issues de QMeshPy/distributed-quantum

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.