Participant Relationship Protocol

Back to matrix

G05-BP: Pending

Rationale

Further pinned ION source tracing establishes three allocation components for each new destination reached through addNode: an IonNode object, its red-black-tree entry and an initially empty embargo list. IonNode contains the destination number, embargo-list address and routing-object address. This is created before the static-exit lookup described in round417. ion.c supplies destroyIonNode and invokes it when dropVdb destroys the complete nodes tree, after routing objects are cleared. Thus a concrete teardown path exists; the inspected source does not establish bounded live eviction for exit-only destinations.

Assessment method

Documentary byte accounting and source-role/lifecycle analysis; no runtime or legal clearance

Source context

Primary RFCs and pinned implementation sources; reviewed 2026-10-22

Outstanding qualification

Still Pending. Inventory allocator, tree, list and lock overhead on the selected ABI rather than equating sizeof(IonNode) with total memory. Search remaining call sites for live reclamation or a supported bounded-routing configuration. Derive the distinct-destination working set per regional gateway from the common workload; 1000 accesses/day/device is not 1000 new destinations and does not force each gateway to see the entire population. Quantify gateway distribution, lookup work, queue and key state. A shutdown cleanup is not online eviction; failure of this ION witness is not an impossibility proof for BPv7. No runtime or whole-repository lifecycle audit performed.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.