Skip to content

docs: document the escrow status model across contract, backend, and clients (#580) - #629

Closed
ZacLou wants to merge 4 commits into
StayLitCodes:mainfrom
ZacLou:docs/escrow-status-mapping
Closed

docs: document the escrow status model across contract, backend, and clients (#580)#629
ZacLou wants to merge 4 commits into
StayLitCodes:mainfrom
ZacLou:docs/escrow-status-mapping

Conversation

@ZacLou

@ZacLou ZacLou commented Aug 29, 2026

Copy link
Copy Markdown

Overview

Fixes #580 — creates docs/STATUS_MAPPING.md reconciling the escrow status representations across all four layers (contract, backend, frontend, mobile).

What's in the doc

Layer source references

Links to the exact file and line numbers where each layer defines its status type:

  • Contract: apps/onchain/src/lib.rs lines 52–61
  • Backend: apps/backend/src/modules/escrow/entities/escrow.entity.ts lines 17–25
  • Frontend: apps/frontend/types/escrow.ts lines 10–24
  • Mobile: apps/mobile/types/escrow.ts lines 1–9

Full mapping table

Every contract status mapped to its backend, frontend, and mobile equivalents with notes. Highlights:

  • funded is a client-only alias for the contract's Active (UI convention)
  • Backend has REFUNDED which has no direct contract equivalent
  • Frontend has intermediate states (confirmed, released) not present on-chain
  • Frontend has legacy uppercase variants (PENDING, ACTIVE, etc.) alongside lowercase

Milestone status mapping

Documents that the contract's Disputed milestone status has no representation on any client — a known gap.

Legal state transition graph

Both the contract transitions (enforced by validate_status_transition in invariants.rs) and the backend transitions (enforced by validateTransition in escrow-state-machine.ts) are documented, including terminal states.

Client-only aliases

Explains each alias with its reason (e.g., funded is used because "Active" is ambiguous to end users).

Three known gaps documented

  1. Contract Resolved has no client representation — clients see COMPLETED or CANCELLED instead
  2. Contract Disputed milestone status has no client representation — rendered as pending
  3. Frontend has mixed-case status union (partial migration) — each status comparison must handle both cases

Each gap includes impact assessment and recommendation.

Cross-references

Linked from docs/contract/DATA_MODELS.md and cross-referenced with EVENTS.md, ERRORS.md, and WORKFLOWS.md.

Acceptance Criteria Checklist

  • A new docs/STATUS_MAPPING.md presents a table mapping every contract status to its backend representation and its frontend/mobile label
  • The legal state-transition graph is documented, including the terminal states enforced by validate_status_transition
  • Milestone statuses are covered alongside escrow statuses
  • Any client-only aliases (for example funded standing in for the contract's Active) are named as aliases, with the reason
  • Gaps where a client cannot represent a contract state are listed as known issues with links
  • The doc is linked from docs/contract/DATA_MODELS.md and referenced by the mobile and frontend type definitions

Closes #580

鲁班七号 added 4 commits August 29, 2026 08:55
…LitCodes#557)

- services/api.ts now imports apiUrl from security/env.ts instead of
  reading EXPO_PUBLIC_API_BASE_URL directly
- EXPO_PUBLIC_API_BASE_URL is fully removed from the codebase
- security/env.ts: corrected dev rpcUrl default from 8545 (EVM port) to
  8000 (Soroban RPC port)
- validateEnv() now provides detailed warnings in development when env
  vars are missing or still using defaults
- validateEnv() is called at app start in app/_layout.tsx
- Added apps/mobile/.env.example documenting EXPO_PUBLIC_APP_ENV,
  EXPO_PUBLIC_API_URL, and EXPO_PUBLIC_RPC_URL

Closes StayLitCodes#557
…tCodes#579)

Created docs/ENVIRONMENT.md listing every env var per service (backend,
frontend, mobile, onchain deployment) with:
- Variable name, owning service, required/optional, secret flag, default
- Conflict & duplicate register (EXPO_PUBLIC_API_BASE_URL vs
  EXPO_PUBLIC_API_URL, NEXT_PUBLIC_API_BASE_URL vs NEXT_PUBLIC_API_URL,
  API_BASE_URL)
- Cross-service variables that must agree (API URL, Stellar network,
  Soroban RPC, contract ID)
- Quick start examples for each service

Closes StayLitCodes#579
Created docs/contract/EVENTS.md documenting:
- Three-part topic convention (Vaultix, v1, EventName)
- EVENT_NAMESPACE and EVENT_SCHEMA_VERSION constants
- All 16 emitted events with topic tuples, payload structs, and field types
- Entrypoint mapping and state transitions for each event
- Events that deviate from the typed-struct pattern (SignatureCollected,
  MultisigConfigured, ContractUpgraded) flagged for convergence
- State transition graph showing legal EscrowStatus transitions
- Schema version bump strategy for consumers

Linked from docs/contract/README.md.

Closes StayLitCodes#578
…nts (StayLitCodes#580)

Created docs/STATUS_MAPPING.md reconciling status representations across
all four layers:
- Contract (Rust): Created, Active, Completed, Cancelled, Disputed,
  Resolved, Expired
- Backend (NestJS): PENDING, ACTIVE, COMPLETED, CANCELLED, DISPUTED,
  EXPIRED, REFUNDED
- Frontend (Next.js): lowercase + legacy uppercase variants
- Mobile (Expo): created, funded, confirmed, released, completed,
  cancelled, disputed, expired

Documents:
- Full mapping table with alias explanations (e.g. 'funded' = contract
  'Active')
- Milestone status mapping (including the missing 'Disputed' milestone
  status on all clients)
- Legal state transition graph for both contract and backend
- Client-only aliases with reasons
- Three known gaps: missing 'Resolved' on clients, missing 'Disputed'
  milestone on clients, mixed-case frontend union

Linked from docs/contract/DATA_MODELS.md.

Closes StayLitCodes#580
@Cedarich Cedarich closed this Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[DOCS] Document the escrow status model across contract, backend, and clients

2 participants