Reporting from the AIBTC landing-page integration side as we build trading-comp attribution and on-chain verification of Bitflow swaps.
Ask
Please consider adding a provider argument to the public swap entry points across:
Currently only xyk-swap-helper-v-1-3 declares the provider field on its swap entry points. The other contracts above don't, which makes off-chain attribution and analytics inconsistent: callers that route through the helper carry a provider tag, callers that route directly through core / stableswap / DLMM / cross-DEX don't, even when the origin of the swap (a user, an agent, a third-party UI) is otherwise identical.
Why parity matters
A provider argument makes attribution on-chain and verifiable — anyone reading the tx event log can identify the origin without needing off-chain heuristics or routing reconstruction. This benefits:
- Comp / leaderboard verifiers (our use case): we verify swap txids against an allowlist of Bitflow contracts and score them per agent. With
provider declared uniformly, we can also distinguish AIBTC-origin swaps from other UI-origin swaps using a single pure-on-chain check.
- Bitflow internal analytics: per-provider volume splits, A/B-style attribution between SDK / UI / aggregator paths.
- Third-party integrators: clear signal of "who routed this swap" without parsing call traces.
Concrete shape
Same shape as xyk-swap-helper-v-1-3 — add an optional provider (e.g. (provider (string-ascii 32)) or a principal type, matching the existing helper's convention) to each public swap entry point, emit it in the swap event payload, and document the recommended values (e.g., "sdk", "ui", "third-party", or a free-form principal/string).
If a breaking change to existing public entry points is undesirable, the parity could be added via:
- New entry-point variants alongside the existing ones (e.g.,
swap-with-provider)
- A new contract version (
xyk-core-v-1-2, DLMM-swap-router-v-1-2) that adds the field
Refs
Happy to provide more context or concrete tx examples on routes that lose attribution — please ping back.
Reporting from the AIBTC landing-page integration side as we build trading-comp attribution and on-chain verification of Bitflow swaps.
Ask
Please consider adding a
providerargument to the public swap entry points across:xyk-core-v-1-1(this repo)stableswap-*pool contracts (likely in BitflowFinance/bitflow-stableswap)DLMM-swap-router-v-1-1(likely in BitflowFinance/bitflow-dlmm)Currently only
xyk-swap-helper-v-1-3declares theproviderfield on its swap entry points. The other contracts above don't, which makes off-chain attribution and analytics inconsistent: callers that route through the helper carry aprovidertag, callers that route directly through core / stableswap / DLMM / cross-DEX don't, even when the origin of the swap (a user, an agent, a third-party UI) is otherwise identical.Why parity matters
A
providerargument makes attribution on-chain and verifiable — anyone reading the tx event log can identify the origin without needing off-chain heuristics or routing reconstruction. This benefits:providerdeclared uniformly, we can also distinguish AIBTC-origin swaps from other UI-origin swaps using a single pure-on-chain check.Concrete shape
Same shape as
xyk-swap-helper-v-1-3— add an optionalprovider(e.g.(provider (string-ascii 32))or a principal type, matching the existing helper's convention) to each public swap entry point, emit it in the swap event payload, and document the recommended values (e.g.,"sdk","ui","third-party", or a free-form principal/string).If a breaking change to existing public entry points is undesirable, the parity could be added via:
swap-with-provider)xyk-core-v-1-2,DLMM-swap-router-v-1-2) that adds the fieldRefs
~/.planning/active/2026-05-08-landing-page-d1-migration/xyk-swap-helper-v-1-3(already declaresprovider)Happy to provide more context or concrete tx examples on routes that lose attribution — please ping back.