Subproject Roadmap

MAKO PayFlow — Standalone Payment Utility

A standalone payment-collection utility any MAKO tool can use to accept payment for its services — MAKO directly, or BNB converted through a capped, proof-gated escrow bridge — with MAKO always deposited to the deployer wallet. Built by the MAKO Posse Team as its own project; a separate SDK Integration Document is the handoff artifact for any team wiring a utility to it, starting with the MAKO Web Team's own tools.

Design and planning complete as of 2026-08-17: Project Description, SDK Integration Document, and POA&M all written and confirmed. No code has been built yet. This page tracks PayFlow's own build — integration into any specific utility is a separate, later effort owned by the consuming team.

Update from MAKO Posse (2026-08-17)

MAKO PayFlow is newly scoped as a standalone project, separate from any individual utility's own codebase. It accepts payment two ways: directly in MAKO on Loop Network (a trivial deposit to the deployer wallet), or in BNB on BSC, which requires a real cross-chain mechanism — the same lock-on-source, cryptographically-prove, release-from-a-capped-escrow design worked out for the Cross-Chain Market Swap Bridge project (now on hold, see the main roadmap's hold list), reused here with the destination fixed to the deployer wallet instead of an arbitrary user. A $5 USD-equivalent per-transaction cap applies, adjustable by the operator without a redeploy. The BNB-side payment collection itself reuses the same proven quote → pay → independently-re-verify pattern already live in production for Contract Scan and Wallet Trace — no new payment mechanism invented from scratch.

Milestones

M1
Project DescriptionPayment model, two-path architecture, the $5 cap, and what's reused vs. genuinely new — all confirmed.
Done
M2
SDK Integration DocumentThe API contract (quote / confirm / status / config) any consuming team builds against, without needing PayFlow's internals.
Done
M3
POA&MTracks PayFlow's own build, milestones, and completion gate.
Done
M4
Roadmap integrationPayFlow added as stage 1 on the main Development Roadmap; the two Cross-Chain Bridge stages moved to an on-hold list pending their own redesign.
Done
M5
Attestation contractNew, separate contract reusing the canonical relay's EIP-712 evidence pattern — not an extension of the governance-gated canonical contract itself.
M6
Capped escrow-release contractFixed-recipient, per-transaction-capped, slice-sized — no bulk pre-funding, holds/queues rather than fails when underfunded.
M7
BNB payment-collection backendReuses the existing Contract Scan/Wallet Trace pattern directly.
M8
Site5 deploymentStandalone hosting, same PHP/cron-driven constraints as the existing MAKO Website utilities.
M9
Real end-to-end test, both payment pathsSmall, real value — same go-live gate standard already used by Contract Scan and Wallet Trace: the operator's own explicit words, not an inferred pass.

Relationship to MAKO Web

PayFlow is built and owned by the MAKO Posse Team as a standalone project — it does not live inside the MAKO Website repository and is not integrated into any utility by this team. Once the SDK Integration Document is finalized against a real, deployed API (POA&M milestone matching M9 above), wiring it into Contract Scan, Wallet Trace, or any future utility is the MAKO Web Team's own responsibility, tracked in that team's own integration POA&M — following the same pattern already used for Contract Scan's own MAKO Web integration.

← Back to Development Roadmap

Source of truth: MAKO PayFlow POA&M v1 (2026-08-17), maintained by the MAKO Posse Team.