Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

feat(reservations): escrow-backed reservations

Aberta
  • Algo errado?
#9 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend, databases

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).

Linguagem predominante
Python
Estrelas
2
Forks
4
Merge médio
6h 14min
PRs com merge (30d)
18

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de QMeshPy/distributed-quantum

Todas as issues de QMeshPy/distributed-quantum

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.