moove.xyz wraps a handle, a contact graph and a referral ledger around on-chain settlement

Bottom line

Every payment in moove.xyz starts from a @moovehandle and ends as an on-chain settlement in the recipient's preferred currency — and the map between those two things lives on moove's servers. That map is the integration. The funds are non-custodial and the transfers are public across 30+ networks, so the part worth reaching is the labeling layer moove keeps: handle-to-address resolution, the profile and its settlement preference, the historical transaction view, contacts, and the referral ledger.

We would build the spine as authorized interface integration of the moove app under a consenting account, joined to per-chain reads so the settled transfer and moove's labeled record line up. Neither half is complete alone. The handle resolution and profile surfaces carry the intent; the chain carries the truth of what moved.

The data behind a @moovehandle

moove's documentation index names its surfaces as Moove Profile, Moove Handle, Moove Contacts, Moove Dashboard, Moove Refer and Moove Widget, plus Send/Receive and Swap. Mapped to what an integrator would pull:

Reaching the handle, ledger and referral layer

Authorized interface integration of the moove app

Protocol analysis of the app's own traffic under your authorization reaches handle resolution, the profile, the dashboard transaction list, contacts and the referral view exactly as moove presents them. Moderate effort. Durability is medium because the app shipped in 2026 and iterates; we account for that in maintenance. Access runs against a consenting account, arranged with you during onboarding.

User-consented account access

Operating through a consenting moove session pulls that account's profile, contacts, dashboard and referral data with the account holder's permission. Lower effort, scoped to one account, and the cleanest fit for a payee or a creator who wants their own history out.

On-chain reconciliation pairing

Because moove is non-custodial, the canonical record of value movement is the chain. Pairing moove's handle and profile resolution with per-chain RPC or indexer reads makes the settled transfers and moove's labels agree. This route is the most durable — on-chain data does not move under you — and it is what closes the gap a swap-and-bridge send opens.

Native export fallback

Where a full feed is not needed, the Moove Dashboard historical view serves as a per-account export for a single account's records.

The route we would actually take is the first joined to the third: interface integration carries intent and labels, on-chain reads carry settlement truth, and together they produce a ledger that holds up under audit. The consented-account route covers the single-account cases without the heavier build.

What the build hands over

Concrete artefacts tied to moove's real surfaces:

• An OpenAPI/Swagger specification for the resolver and the dashboard reader — handle in, address-per-chain plus settlement asset out; transaction list with the swap/bridge route fields.
• A protocol and auth-flow report covering the session/token chain the app uses, how a consenting account is attached, and how requests are signed or carried.
• Runnable source for the key calls in Python and Node.js: resolve a handle, read a profile, page the transaction history, pull the referral ledger.
• Automated tests, including unknown-handle and unresolved-naming-service cases and a reconciliation test against an on-chain read.
• Interface documentation and data-retention guidance written for Hong Kong's PDPO, with consent scope and revocation handling spelled out.

Resolving a handle, then reading the settled transaction

Illustrative shape of the spine; exact field names are confirmed during the build against the live app.

# 1) Resolve a @moovehandle to a payable destination
GET /resolve?handle=@aria.moove
Authorization: Bearer <session-from-consenting-account>

200 OK
{
  "handle": "@aria.moove",
  "profile": { "display": "Aria", "settlement_asset": "USDC",
               "settlement_chain": "base" },
  "addresses": [
    { "chain": "base",     "address": "0x9f...c2" },
    { "chain": "solana",   "address": "7Qd...k1" }
  ],
  "naming_source": "moove"            # or an external naming service
}

# 2) Read the labeled transaction, then verify it on-chain
GET /tx?handle=@aria.moove&cursor=...
-> { "id": "mv_8841", "from": "@dev.moove", "to": "@aria.moove",
     "source_asset": "ETH", "settled_asset": "USDC",
     "route": ["swap:ETH->USDC", "bridge:eth->base"],
     "chain": "base", "status": "settled", "ts": "2026-05-11T08:22Z" }

# error handling
404  unknown_handle            -> surface as unresolved, do not guess
409  naming_service_unresolved -> retry via fallback resolver
# then confirm settled_asset/amount against a base RPC read for mv_8841
      

Personal data under Hong Kong's PDPO, and the virtual-asset backdrop

moove.xyz lists a Causeway Bay, Hong Kong address on its Play Store listing. The personal data in a Moove Profile and in Moove Contacts — usernames, images, bios, social links, a contact graph — is personal data under the Personal Data (Privacy) Ordinance, Cap. 486, enforced by the Office of the Privacy Commissioner for Personal Data through its six Data Protection Principles. An integration touching that data carries a defined purpose, consent that can be withdrawn, and minimisation to the fields the use actually needs.

The asset movement sits against Hong Kong's virtual-asset licensing regime under the Anti-Money Laundering and Counter-Terrorist Financing Ordinance, administered by the Securities and Futures Commission; a 2025 SFC and FSTB consultation proposed extending licensing to virtual-asset dealing and custody. moove describes itself as non-custodial and operating without KYC; its own Hong Kong licensing status is not publicly disclosed and is not asserted here. Our posture is fixed regardless: authorized or user-consented access only, consent records and request logs kept, data minimised, and an NDA where the work touches a client's account.

Things this integration has to get right

The split between label and settlement. Non-custodial means moove's database is the meaning of a payment and the chain is the fact of it. We design the join so a send is reconciled against the actual on-chain transfer, not trusted from the app's summary line alone — that is what keeps a derived ledger audit-clean.

Two resolution paths for one handle. A @moovehandle can resolve through moove's own directory or through a supported decentralised naming service. We map both paths so a handle that ultimately points at an external name still returns the correct destination address per chain, with the source recorded.

A send is a route, not a transfer. Source asset auto-detection, a cross-token swap, a cross-chain bridge and settlement in the payee's preferred currency can all be one user action. We model each leg so the integrator's record reflects what settled where, including the intermediate hops.

Settlement preference is per profile. What an inbound payment lands as depends on the recipient's chosen settlement asset and chain. We read that from the profile surface so a payer-side integration predicts the settled asset before sending rather than after.

Access is arranged with you at onboarding; the build runs against a consenting account, and the moove-side surfaces are mapped from that.

Where teams plug this in

• A merchant tool that resolves a customer's @moovehandle, shows the address and the currency the customer will be paid in, then watches the chain for the settled inbound.
• A creator's accounting export pulling their own Moove Dashboard history with swap/bridge legs itemised for tax records.
• A referral-payout reconciler matching Moove Refer's daily USDC rewards and ambassador tallies against on-chain payouts.
• An address-book sync that keeps a CRM's payee list current from a consenting account's Moove Contacts.

Keeping the feed honest as moove ships

moove launched in 2026 and moves fast. We agree a recheck rhythm up front so a change to the app's client surface shows up as a flagged maintenance item rather than a silent gap in the feed, and the on-chain reconciliation acts as a continuous check — if the labeled view and the chain stop agreeing, that is the signal something shifted.

Screens we worked from

How this brief was put together

Worked from moove's own platform page and its public documentation index for the surface names and the handle/naming behaviour, the Play Store listing for the company location and the five product pillars, recent launch coverage for the non-custodial and no-KYC posture, and Hong Kong's data-protection regulator and the SFC virtual-asset materials for the legal frame. Checked May 2026.

• moove.xyz official platform page
• moove.xyz documentation index (products and naming services)
• Launch coverage: non-custodial, no-KYC cross-chain payments
• PCPD — Personal Data (Privacy) Ordinance overview

OpenBanking Studio · integration desk assessment, 2026-05-17.

Other apps in the same payments-and-handles space

Named for ecosystem context — a unified integration usually has to read more than one of these:

• Phantom — multi-chain non-custodial wallet holding addresses, balances and swap history a payee integration would mirror.
• Solflare — Solana-centred wallet with staking and transaction records; a connected source for moove receivers.
• Backpack — wallet with in-app applications, holding account and transaction state alongside moove handles.
• MetaMask — widely connected EVM wallet whose address and activity often back the same flows moove labels.
• Trust Wallet — multi-chain wallet with portfolio and transfer history relevant to cross-chain reconciliation.
• Coinbase Wallet — self-custody wallet whose address book and history overlap with a moove contact graph.
• Zerion — portfolio tracker aggregating multi-chain positions and history useful as a reconciliation cross-check.
• Rainbow — Ethereum wallet with profile-style identity and transaction history comparable to a Moove Profile.
• Request Finance — crypto invoicing and payment records that pair with moove's transaction labeling for accounting.

Questions integrators ask about moove.xyz

Since moove.xyz is non-custodial, what does its server actually hold that is worth integrating?

The funds never sit with moove, but the meaning of each payment does. The server holds the @moovehandle to wallet-address map, the profile (username, images, bio, social links, preferred settlement currency), the historical transaction list as moove labels it, saved and recent contacts, and the referral ledger with daily USDC rewards. The settlement itself is public on-chain across 30+ networks; we join moove's labeled view to those reads so the two reconcile.

Can a @moovehandle be resolved to a destination address programmatically?

Yes — handle resolution is the spine of any moove integration. moove resolves its own handles and, per its documentation index, supported decentralised naming services. We deliver a resolver that takes a handle and returns the destination address per chain plus the profile's preferred settlement asset, so a payer integration knows where value goes and what it lands as.

Which Hong Kong rules apply to a moove.xyz integration?

moove.xyz lists a Causeway Bay, Hong Kong address on its Play listing, so the personal data in profiles and contacts falls under the Personal Data (Privacy) Ordinance (Cap. 486), enforced by the PCPD under its six Data Protection Principles. Hong Kong's virtual-asset licensing regime under the AMLO, administered by the SFC, is the backdrop for the asset movement; moove describes itself as non-custodial and no-KYC, and its own licensing status is not publicly disclosed and is not asserted here. We operate authorized, consented and logged.

Do you reconcile the swap-and-bridge route, or just the headline transfer?

A single moove send can auto-detect the source asset, swap it, bridge it across chains, and settle in the recipient's preferred currency. We model that as a route, not one transfer, and reconcile each leg against on-chain reads so an integrator's ledger matches what actually settled rather than only moove's summary line.

Source for the resolver and the dashboard reader is delivered in one to two weeks. You pay from $300 after delivery, once it runs against your consenting account and you are satisfied — or skip the upfront entirely and call our hosted endpoints per request with no fixed fee. Give us the account and what you need from its data at /contact.html and we map the moove surfaces from there.