Capstone: extend the protocol end to end

The project

This capstone is where everything converges. You will extend the XRP Ledger protocol end to end, exactly the way a core developer would: a new transaction type, gated behind an amendment, with an RPC command to read its state, and tests to prove it works.

You have already done each piece in isolation: a transactor case study (CheckCreate), a custom RPC handler, and the amendment machinery. Now you put them together on your own feature.

Choose a feature

Pick something small but real. Ideas (or bring your own):

• Deposit lock: an account flag plus transaction that time-locks incoming XRP above a threshold.
• Recurring allowance: a ledger object that lets a designated account pull up to N XRP per period (a simplified version of the Subscriptions example used in the amendment modules).
• Account note: a small on-ledger key-value note object with create/update/delete transactions and reserve handling.

Keep the scope tight: one new ledger entry type at most, one to three transactions, one RPC command.

Requirements

1. Amendment: register a feature flag; all new behaviour must be gated on it (ctx.rules.enabled(...)).
2. Transactor(s): implement preflight, preclaim, and doApply with correct TER codes, reserve checking, and owner-directory handling.
3. RPC command: a read-only handler that surfaces your new state, registered with an appropriate role.
4. Tests: jtx unit tests covering the happy path, the main error paths, and behaviour with the amendment disabled.
5. Demo: in standalone mode, enable your amendment, create and fund your test accounts (funding loop: see the Build & run your own xrpld node module, "Create and fund test accounts"), run your transactions, query your RPC command, and capture the session.

Deliverable

A branch (or patch series) against rippled 3.2.0, plus a short design note (1-2 pages): what the feature does, the ledger-entry format, the TER codes you chose and why, and what you would harden before proposing it for real. A mentor reviews the whole package.

Advice

• Start from the CheckCreate family as a template; copy its structure, then diverge.
• Commit early and often; keep the amendment gate in from the first commit.
• When something behaves oddly, standalone mode plus trace logging is your friend.
• Do not chase completeness. A small feature done correctly, with honest tests, is the goal.