A new XRPLF position. XRPL has a well-defined process for getting code into xrpld and amendments activated; there is no equivalent end-to-end ownership of getting an amendment successfully into the ecosystem. The Amendment Manager owns that gap: one owner per amendment from spec to product, every stage of the pipeline in amendment-duties.md, for the amendments assigned to them. It is a hybrid seat, half management and half hands-on development. The management half runs the people and vendors who build the protocol layer; the dev half personally builds the ecosystem layer around it, because reference implementations, SDK parity, and signing-device support are exactly the work that today has no owner.
Published page: https://claude.ai/code/artifact/b4df82c2-c744-45cc-a24e-a451ffcfe9c8 Gist: https://gist.github.com/dangell7/53927cc777636956d14c508b028f2e47
Management:
- Spec — author or shepherd the XLS through XRPL-Standards, own revisions, keep the spec current as the implementation moves, and carry ecosystem feedback back into the design while it can still change.
- C++ developer — scope and track the rippled implementation engineer (in-house or vendor): the PR, tests to audit-ready, rebase upkeep.
- Review and audit — procure and schedule the two reviewers and two auditors, drive each review round and audit remediation to closure.
- Integration — wallets, exchanges, and infrastructure providers: notice with lead time before activation, then hands-on support for a bounded slice (the first two or three integrators per amendment, or a standing office-hours slot plus issue queue); docs and the reference implementation carry the rest. Keep integrators interpreting the primitive the same way; divergent implementations are a defect to catch here, not after launch.
- Parity — documentation, spec, and implementation say the same thing at every stage. The manager writes the xrpl.org docs (the dev slice of this duty) and treats drift between the three as a defect to fix now, not at audit time.
- Activation — devnet and testnet deployment, validator outreach and voting materials so validators vote informed, the flag-window watch, fix-amendment readiness, and the readiness call: knowing whether the ecosystem is genuinely ready as activation approaches.
- Adoption — track who supports the amendment, who does not, and what is blocking them; developer education and examples. Awareness campaigns and community engagement stay with XRPLF comms.
Development:
- Reference implementation — the open-source front-end per net-new primitive, exercising every new transaction type on testnet. Where how the feature reaches users is not obvious (SDK-only, reference UI, hosted service, wallet-native), step one is a one-page delivery decision; obvious cases skip straight to building.
- SDKs and tooling — definitions and models in xrpl.js, xrpl-py, xrpl4j, and xrpl-go (code-gen where it exists, hand parity where it does not), Clio support, and any purpose tooling the primitive needs.
- Signing devices — maintain the per-amendment signing compatibility matrix: which wallets and devices can sign every new transaction type, what is missing, and each vendor's process for adding it. The manager builds the ledger-app-xrp and Ledger Live updates personally, through Ledger's review process, ready on activation day; other vendors' gaps are driven through their contribution processes.
- Devnet metrics dashboard — a dashboard on the devnet tracking the amendment's new transaction types: volume, result codes, failure patterns, and which accounts and paths are exercising them, with an AI layer analyzing how the primitive is actually being used: the flows developers build, misuse and misunderstanding of the spec, and edge cases nobody is hitting. It shows whether the primitive is actually being tested (not just that tests exist), feeds the readiness call in duty 6 with numbers instead of impressions, and feeds what the analysis surfaces back into the spec and docs (duties 1 and 5). Spec: amendment-dashboard-spec.md / https://gist.github.com/dangell7/ad1e338ba953e6152ab3d07f3227fb86
- Maintenance — the manager maintains their own artifacts (reference UIs, SDK contributions, device app updates, dashboards, docs) after activation, and keeps the playbook: lessons from each amendment carry to the next instead of being rediscovered.
- Appetite discovery. Integration is assumed; providers get notice and support, not a market study per amendment.
- Supporting service infrastructure. A per-amendment backend (API, hosting, monitoring) is permanent opex; if a delivery decision calls for one, it is a case-by-case budget gate and vendor engagement, not a role duty.
- Awareness and comms. XRPLF comms runs campaigns; the manager supplies the technical material and the adoption picture.
A full-stack engineer who can run a process, not a project manager who can read code. Required: TypeScript/React for the reference UIs; client-SDK internals (definitions.json, binary codec) for parity work; C++ read-fluency, enough to review the rippled diff against the spec and manage the implementation engineer credibly; XLS process fluency; vendor and audit procurement. The Ledger app is embedded C against Ledger's SDK, a narrower skill: the manager either has it or manages a standing contractor for it, and we should not filter the hire on it.
Review and audit are wait states, so one manager pipelines amendments rather than running one at a time: while amendment A sits in its audit window, B is in review rounds and C's reference UI is being built. The throughput limiter is the dev half. Working estimate: 3-4 amendments in flight, 4-6 taken to merge-ready or activated per year. The 2027 list (5 committed audits + 3 contingent) fits one manager with vendor engagements absorbing reference-UI overflow; a second seat is warranted only if the contingent gates open.
- Amendments taken to merge-ready or activated per year (target 4-6).
- Client library parity within 4 weeks of the rippled release that ships the amendment.
- Signing matrix complete with the Ledger row green, and xrpl.org docs live, on activation day, not after.
- Adoption picture current per active amendment: who supports it, who is blocked, and why.
- Zero audit findings attributable to spec-implementation drift.
$200-250k (EUR 172,414-215,517 at the 1.16 convention). Below the senior core C++ seats on the hiring board: the C++ authorship stays with the protocol engineers. Above pure-PM comp: the dev half is real engineering across four surfaces (web, SDK internals, embedded, docs). The work-sample filter writes itself: take a small shipped amendment and deliver its reference UI plus one SDK's definitions in N weeks.