Maintenance commitment
This document is a 12-month maintenance commitment for the Stellar Passkey Kit, scoped to the SCF-43 RFP submission and extending through the first quarter past it.
Active maintainer roster
| Role | Identity | GitHub | Term |
|---|---|---|---|
| Primary maintainer | Tolga Yaycı | @tolgayayci | 2026-05-19 → 2027-05-19 (renewed annually) |
| Named secondary maintainer | Mert | @justmert | 2026-05-19 → 2027-05-19 (renewed annually) |
| Security disclosure | per SECURITY.md (forwarded to primary + secondary) | — | continuous |
Both maintainers commit to the cadence in the calendar table below. Renewal of either role happens by simultaneous commit to this file on each Anniversary cycle, signed by the renewing party's SSH key.
Public update channel
The GitHub Releases feed is the canonical update channel:
- HTML — https://github.com/justmert/stellar-passkey-kit/releases
- RSS / Atom — https://github.com/justmert/stellar-passkey-kit/releases.atom
This satisfies the SCF RFP's "commitment to regularly updating the community on project status" requirement without taking a dependency on a centralised analytics or social network. RSS readers, GitHub's release notification subscriptions, and mirrors that follow tag pushes all see updates with no extra infrastructure. A BlueSky cross-post channel (@stellar-passkey-kit.bsky.social) is planned under YK-285 and will be added to this list if/when it goes live.
12-month calendar
Each row is the planned work for that month. Both maintainers acknowledge the cadence; deviations from this calendar are recorded as amendment commits to this file.
| Month | CI farm run (1st BD) | Matrix snapshot | Release cadence | Other |
|---|---|---|---|---|
| 2026-06 | matrix-v2026.06.01 | — | 0.1.x patch as needed | Watch SCF-43 review thread; respond within 48 h. |
| 2026-07 | matrix-v2026.07.01 | Quarterly bump → matrix-v2026.Q3 | 0.1.x patch as needed | Begin upstream-PR review iteration (YK-298). |
| 2026-08 | matrix-v2026.08.01 | — | 0.1.x patch as needed | Real-device YubiKey hw-bench (YK-296) and BrowserStack run #1 (YK-297). |
| 2026-09 | matrix-v2026.09.01 | — | Possible 0.2.0 if upstream PR merges | Audit Bank submission (YK-300) if PR has merged. |
| 2026-10 | matrix-v2026.10.01 | Quarterly bump → matrix-v2026.Q4 | 0.2.x patch | BrowserStack run #2 (YK-297). Stellar protocol release-watch (Soroban upgrade window). |
| 2026-11 | matrix-v2026.11.01 | — | 0.2.x patch | YubiKey hw-bench re-run; matrix row refresh. |
| 2026-12 | matrix-v2026.12.01 | — | 0.2.x patch | Year-end review post on the Releases feed; archive any stale Discussion threads. |
| 2027-01 | matrix-v2027.01.01 | Quarterly bump → matrix-v2027.Q1 | 0.3.0 minor if Protocol-N+1 lands | Re-run e2e against mainnet upgrade window. |
| 2027-02 | matrix-v2027.02.01 | — | 0.3.x patch | BrowserStack run #3. |
| 2027-03 | matrix-v2027.03.01 | — | 0.3.x patch | OZ Verifier-trait migration evaluation (YK-301), gated on OZ stable release. |
| 2027-04 | matrix-v2027.04.01 | Quarterly bump → matrix-v2027.Q2 | 0.3.x patch | YubiKey hw-bench re-run; renewal-eligibility review. |
| 2027-05 | matrix-v2027.05.01 | — | 0.4.0 or 1.0.0 candidate | Annual maintainer roster renewal commit. |
Calendar cadence (rules)
The 12-row table above is the plan; the rules below are the invariants that hold beyond the 12-month window.
- Monthly — first business day of every month. Manually trigger the matrix CI farm (
gh workflow run matrix-ci.yml). Review failures, file regressions in Linear within 48 h. Recorded indocs/matrix/data.json. - Quarterly — first business day of the quarter. Bump matrix version (
matrix-vYYYY.Qn), publish CHANGELOG entry + a GitHub Release (which the Releases-feed RSS picks up), and post a status update on the upstream Discussion thread. - On every Stellar mainnet upgrade. Re-run the e2e test suite against the new protocol version within 5 business days; publish a compatibility note as a GitHub Release.
- On every PR. Mandatory CI gates: typecheck, unit, e2e (Chromium), security workflow (cargo-audit, npm-audit, clippy).
Deprecation policy
Any breaking change to the public SDK surface (functions exported from @stellar-passkey/core/{create,connect,sign,recover}) MUST ship with ≥ 3 months of deprecation notice, posted simultaneously to:
- CHANGELOG.md (
### Deprecatedsection per keep-a-changelog). - The BlueSky update channel.
- The upstream Stellar-Wallets-Kit Discussion thread (PSK-003).
- A new pinned issue in this repository.
Removal of a deprecated API requires a major version bump.
Security disclosure flow
Vulnerabilities are reported per SECURITY.md — a private email goes to both the primary and secondary maintainer, the issue is acknowledged within 72 hours, and a patched release ships within 14 days of report (mainnet-impacting issues) or 30 days (testnet-only).
Org-transfer plan
If the primary maintainer is unable to continue (extended absence, abandonment), the secondary maintainer triggers the following sequence:
- Open a GitHub issue titled
[maintainer-transfer]referencing this document. - After a 30-day public window for objections, request a GitHub org transfer of
justmert/stellar-passkey-kitto a community-elected maintainer or to the @CreitTech organisation as a successor. - Update this file with the new roster and the transfer commit hash.
The transfer triggers are publicly observable: 60 consecutive days without a maintainer commit, public statement of step-down, or unrecoverable contact loss confirmed by two community members.
Sunset clause
If the SCF-43 PR is rejected and no alternative integration path emerges within 90 days, this document and the matrix CI farm continue to run for the remainder of the 12-month commitment, then the project is archived rather than abandoned — code remains MIT-licensed and the repository stays public.