Skip to content

Implement chosen release() authorization mechanism #21

Description

@Codex723

ISSUE #21


Category: Escrow Contract
Difficulty: advanced
Labels: soroban, rust, advanced

Files involved

  • contracts/escrow/src/lib.rs

Background

Depends on the RFC issue above. Implement the agreed authorization check (signature verification, multi-sig, or oracle/timelock) before releasing funds.

This issue is part of the RemitX contributor backlog, generated from a full codebase audit of the project. RemitX is a Stellar-based remittance platform (Next.js 16, Prisma/Postgres, the Stellar SDK, and a Soroban escrow contract) currently at the "foundation build" stage: auth and the data model are real, while the Stellar integration, escrow contract internals, and several frontend pages are intentionally scaffolded with TODO(contributor) markers. See FOUNDATION.md in the repo root for the full project map and current status of every subsystem before starting.

Suggested approach

  1. Review the current implementation in contracts/escrow/src/lib.rs and confirm the stub/gap described below.
  2. Depends on the RFC issue above. Implement the agreed authorization check (signature verification, multi-sig, or oracle/timelock) before releasing funds.
  3. Handle the edge cases and failure modes called out in the acceptance criteria below (e.g. unauthorized release() calls fail).
  4. Add or update tests so the behavior is verifiable and won't silently regress.
  5. Update any relevant comments/docs (e.g. remove the TODO(contributor) marker this issue resolves, if applicable).

Acceptance criteria

  • Unauthorized release() calls fail
  • Authorized release() calls succeed and transfer funds
  • Test covers both the happy path and rejection path

Notes for contributors

  • Keep the change scoped to this issue — if you notice other stubs or bugs nearby, open a separate issue rather than bundling fixes into this PR.
  • Match the existing code style in the surrounding file. This codebase uses TypeScript strict mode, Zod for input validation, and the shared successResponse/errorResponse helpers in src/lib/api-response.ts for every API route.
  • If this issue depends on another issue in this area being done first, check the related issues below before starting — some subsystems (e.g. the escrow contract's release() authorization) need a design decision made before implementation can proceed.
  • Please reference this issue number in your PR description, and check off acceptance criteria as you satisfy them.

Related issues in this area

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions