---
title: Short title of the change
description: One sentence. What would move, and why it cannot wait.
status: draft
type: core
author: Your name
date: 2026-09-09
---

This file is a template. It is not a PIP on the register. Replace every sentence that describes your change. Leave the headings. PATH writes the number and the status when the form is received — you do not pick a PIP-0000 yourself.

Types: `core` · `networking` · `interface` · `informational` · `process` · `meta`

## Why

The specification is silent, or wrong, or it names something that cannot be implemented as written. State the defect in the current draft. Do not write a slogan.

Example of the register this template is modelled on: identifier hashing is server-side. Calling it zero knowledge is false. A PIP that repeats that lie will be refused.

## What must not change

List the invariants. Finder stays SONAR then RESOLVER, composed on the client. A directory remains a club. PATH does not admit members. Liquidity stays reserved unless this PIP is specifically about filling `route` — and then say so.

If your change would break one of those, say so here. Do not hide it.

## The change

What an implementer would do differently after this PIP is Implemented.

1. First concrete step.
2. Second concrete step.
3. What an existing v0.1.0 implementation must keep doing until a dated switch.

## Compatibility

What still verifies. What stops verifying. Whether this needs a protocol bump, an API date, or only a note.

A silent swap that makes two members unable to find each other is a reason to refuse.

## Refusal conditions

Write the lines that would make this PIP false. PATH will use them.

- A claim the specification already forbids.
- A design that puts SONAR and RESOLVER in one party’s hands.
- A request to be seated in a directory.