Skip to main content
LumenWipe ends every close in an irreversible merge of a user’s funds, so a small set of paths decides whether that merge goes where the user asked. This page lists them by path, says why each is sensitive, and names the owner role and the review a change there needs. It is the path list behind the closer-review rule in CONTRIBUTING.md. The threat model explains the threats these paths answer, and the invariant register says which of their guarantees a test proves. bun run check:docs fails the build when a path below no longer exists, so a move or a rename has to update this page in the same pull request. It does not check that the list is complete: a new sensitive file is added here by the pull request that creates it.

​
Owner roles

Roles, not people, so the page survives absences. A maintainer may hold more than one.
  • Verification owner: the browser and playground trust anchors, client-side signing and its orchestration, and the SDK’s close runner. Everything that decides what a user signs.
  • API owner: transaction construction, the account reads verify() relies on, the two server-side Stellar signing keys, authentication and key issuance, and the contract and exchange registries.
  • Infrastructure owner: the web server’s proxy and Content Security Policy, CI, deploy and dependency configuration, and the documents and checks that define this scope.

​
Security-sensitive paths

A file listed here stays in scope even when it sits under a directory the last section leaves out.

​
The closer-review rule

A pull request that touches any path above:
  1. Says so in its description and names each group it touches.
  2. Gets a security review of its diff before it is opened, recorded in the description: what was checked and what was found. Maintainers run their security review tooling for this; an outside contributor asks a maintainer to.
  3. Gets an approving review from the owner of each group it touches, or, for a group whose owner is the author, from another maintainer. One maintainer holding several roles can approve for all of them. When no other maintainer is available, the pull request waits. The approver reads the whole diff of each group, not only its tests.
  4. When it adds a close operation, a signing key, an adapter, a surface or an app boundary, updates the threat model and the invariant register in the same pull request.
The rule is applied by the author and the reviewer. As of 2026-10-13, GitHub does not enforce it: the repository has no CODEOWNERS file and requires no approving review count, so the required CI checks are the only automatic gate.

​
Out of scope

These carry no fund path or key, so ordinary review applies:
  • The playground’s UI: apps/playground/app/ and apps/playground/components/, except apps/playground/app/api/ and the files listed above.
  • The marketing pages: apps/web/app/(marketing)/.
  • The docs site under docs/, except the pages listed above. For other pages, review covers their claims; bun run check:docs only confirms that the files, symbols and tests they name exist.