Launchpad adapters

A launchpad integration has two distinct surfaces: asset discovery and host-page injection. They can share normalized identity logic, but neither surface is allowed to bypass market eligibility or settlement controls.

Discovery adapter

A discovery adapter maps a launchpad API or onchain source into normalized assets. It should provide:

a stable launchpad identifier;
chain and canonical asset address;
symbol, name and image URL;
launch phase and capability fields;
source timestamps and pagination cursor;
explicit missing-data states;
conservative request rate and cache TTL.

Broad Explore listings can remain in a local TTL cache. The backend persists an asset when it enters the durable market workflow.

Injection adapter

The injection adapter locates token cards and detail views, adds a compact prediction control and anchors the panel without breaking the host site.

An adapter must handle:

client-side navigation and virtualized lists;
delayed image and font layout;
card reuse during scrolling;
resize and mutation observation;
host dialogs and stacking contexts;
pointer-event isolation so a Pools Markets control does not trigger the host card;
cleanup when an anchor leaves the document.

Shared anchoring and lifecycle code should solve generic drift. Site-specific selectors and placement policies remain isolated in the adapter because host DOM contracts differ.

Security boundary

Host content is untrusted. DOM text must be parsed and validated as data. A host page cannot choose market rules, settlement sources, user account permissions or transaction calldata.

Integration acceptance

Before a launchpad is marked supported, confirm:

stable asset identity across list and detail views;
no duplicate controls during scroll or rerender;
controls remain within intended card bounds;
host dialogs correctly hide or defer Pools Markets surfaces;
discovery requests respect the source’s contract;
missing or stale fields cannot create an unsafe market.