Skip to main content

​
What the App is for

The App is the main control surface for Parly users. It is where a user connects a wallet, authenticates private state, shields supported stablecoins, executes private payouts, reviews activity, prepares selective-disclosure records, and hands a disclosed lane to the Verify portal when proof is needed.

​
Connect and authenticate

Parly does not treat wallet connection and private-state access as the same thing. Connecting a wallet gives the application an active address. Authenticating that wallet activates private-state recovery and execution by asking the wallet to sign a fixed authentication message. That message is used to derive the recovery identity used for private note recovery. In practical terms, the flow is:
  1. Connect wallet
  2. Authenticate
  3. Recover private state
  4. Use Shield, Execute, Ledger, and Verify

​
Shield

Shielding moves supported stablecoins into a private balance on Tempo. There are two shielding paths:
  • direct shielding on Tempo
  • spoke-origin shielding into Tempo
Both paths are part of the live product surface. The Shield experience should guide the user through network selection, asset selection, amount entry, approval where required, confirmation, and confirmed private-balance entry.

​
Execute

The Execute surface is where a user spends from private balance. It supports:
  • single send
  • batch send
  • private same-network payouts on Tempo
  • private cross-network stablecoin-only payouts to supported spokes
  • private relay by default
  • self-relay fallback
The interface must keep submitted, pending, confirmed, and failed visually distinct.

​
Ledger and Compliance

The App includes a Ledger and Compliance surface directly below the main execution console. This is where users review deposits, private executions, change-note activity, scoped payout records, and disclosure-preparation flows. The compliance model is selective by design. A user can review one payout scope at a time, export a lane-scoped record, and hand that record to a counterparty, auditor, or exchange without exposing the wider private execution set. This surface should be treated as:
  • a review surface
  • a receipt surface
  • a proof-preparation surface

​
Scoped receipts

A scoped receipt is a record for one disclosed payout lane. Depending on what is truthfully available, a scoped receipt may include confirmed settlement facts, the disclosed payout scope, local note relationship details where appropriate, and provenance details where the source and settlement path can be linked honestly.

​
Verification handoff

When a scoped receipt is shared, the recipient can independently verify the disclosed payout lane using the Verify portal. The typical handoff is:
  • the confirmed Tempo transaction hash
  • the disclosed child key

​
Product behavior

The App is designed to keep execution, review, and proof connected. Shielding, sending, history, receipts, and verification handoff belong to one coherent operating surface.