Local2Coin Documentation

Local2Coin Documentation

Local2Coin is built on the P2Pagos open-source multi-rail payment infrastructure.

P2Pagos uses:

• /mono as the Nuxt-based orchestrator repo.
• /wallet as the mobile self-custodial settlement wallet, based on an Aqua Wallet fork.
• /dashboard as the embedded Nuxt mini app for /wallet settings and flows, replicable on desktop.
• /marketplace as the closed-source multi-user layer built on top of /mono.
• BTCPay Server as the backend for settlement infrastructure.

The stack is designed around:

• inbound rails
• modular services
• self-custodial settlement
• multi-rail payment architecture
• practical cross-border money movement
• reduced dependency on a single processor, bank, country, or rail

Repository roles

Architecture

/mono

/mono is the orchestrator repo for P2Pagos.

It assembles payment rails, business flows, infrastructure services, and shared utilities into a single Nuxt-based workspace.

This repository is still being cleaned up and should be read as an early orchestrator base, not as a finished product.

Structure

/
├── nuxt.config.js      root Nuxt app — loads all workspace modules
├── app.vue
├── pages/
├── server/
├── rails/              payment rail modules
├── flows/              business flow modules
├── services/           infrastructure service modules
└── utils/              shared utilities

What /mono is not

• Not a finished marketplace.
• Not a polished public SDK.
• Not stable enough yet to promise broad production use.

/mono modules

Rails

Payment rail modules inject pages, composables, and server handlers into the host app. They can also run standalone as Nitro servers.

Flows

Higher-level feature modules with pages and UI components.

Services

Infrastructure modules that run both as standalone Nitro apps and embeddable Nuxt modules.

Inbound multi-rails

Service modules

/mono local development

pnpm install
pnpm dev
pnpm build
pnpm preview

/mono module loading

The root Nuxt app loads workspace modules through nuxt.config.js.

Adding a module requires:

1. Add "@p2pagos/<name>": "workspace:*" to root package.json dependencies.
2. Add '@p2pagos/<name>' to the modules array in nuxt.config.js.

flows/booking requires @nuxt/ui. It must be present in nuxt.config.js before or alongside the booking module.

/mono environment variables

services/tor

rails/robosats

rails/peach

services/ip

services/market

/mono known issues

/wallet

/wallet is the mobile self-custodial wallet for P2Pagos, based on an Aqua Wallet fork.

This repository exists because Aqua already provides a strong base for the settlement layer P2Pagos needs, while still allowing extension toward P2Pagos-specific payment flows, settings management, and marketplace integrations.

Why Aqua Wallet

Aqua Wallet was selected as the base for this fork because it already provides:

/wallet planned changes

The current fork is intended to evolve into the P2Pagos mobile settlement and configuration wallet.

Planned changes include:

• Add self-custodial Polygon wallet support derived from the existing seed phrase, in order to support USDT on Polygon.
• If needed for future rails settling in USDT on other chains, extend support through USDT0-based interoperability, using Polygon as the main anchor network.
• Replace Aqua's marketplace tab with a dedicated Payments tab powered by the /dashboard Nuxt mini app.
• Integrate exchange rates from yadio.io, which are more representative of real pricing in emerging markets than exchange-only sources such as Kraken.
• Continuously improve core functionality while regularly pulling upstream changes from Aqua.
• Remove the distinction between Saving Account for BTC and Spending Accounts for other assets, in order to better fit the P2Pagos payment-oriented product model.
• Add Russian and remove unnecessary languages, aligning the wallet with the default language set: EN, ES, PT, FR, IT, RU.
• Rebrand the application as part of the P2Pagos product family.

USDT on Polygon

One of the main planned additions is self-custodial USDT support on Polygon.

The goal is to give users access to a settlement asset that is widely usable across integrable payment rails, while preserving the same wallet ownership model already used for Bitcoin and Liquid assets.

The implementation is designed around:

• deriving Polygon wallet support from the same existing seed phrase;
• supporting USDT on Polygon as a first-class settlement asset;
• using a Flutter EVM stack for Polygon account derivation, signing, and contract interaction;
• evaluating web3dart and onchainlabs_flutter;
• minimizing user exposure to native-token operational complexity;
• enabling network fee handling through an ERC-4337 paymaster flow;
• abstracting fees from the normal user experience;
• charging fees in USDT instead of requiring manual MATIC management.

This is intended to make USDT settlement operationally simpler for users who need stablecoin-based final settlement without unnecessary wallet fragmentation.

/dashboard mini app integration

The /dashboard mini app will be integrated into the wallet through a WebView-based approach.

Security model:

The embedded Nuxt app does not receive direct access to secrets.

The bridge is limited to the data and actions required for the payment UI, such as:

• receiving addresses
• basic wallet context
• signing requests

This keeps sensitive key material inside the native wallet layer while allowing P2Pagos-specific flows and settings to be built in Nuxt.

/wallet scope

The /wallet repository should be read as the mobile wallet layer of the broader P2Pagos architecture.

It is not just a generic wallet fork.

Its purpose is to provide:

• self-custodial settlement for Bitcoin, Liquid assets, and future supported rails;
• secure connection to BTCPay Server and related payment infrastructure;
• an embedded interface for /dashboard and payment-related flows;
• a mobile foundation for users interacting with /mono instances and connected marketplace environments.

Settlement flow summary

Operational model

Current status

P2Pagos is still evolving.

Some components exist as working integrations. Others are partial, experimental, planned, or still being assembled into the main orchestrator.

The repositories should be read as active infrastructure work, not as a finished product suite.