STEALTHSWAP NATIVE ESCROW PARTICIPANT TOOL

Bitcoin: live only when the website explicitly offers Bitcoin mainnet.
Monero: mainnet only when explicitly offered, with experimental risk consent.
TRON: native TRX only when explicitly offered; customer-paid deployment.
No currency conversion. No platform escrow fee. No operator funding wallet.
Bitcoin funding uses 6 confirmations. Any two of the three key holders can
spend. There is NO automatic timeout refund. Choose and authenticate your
independent arbiter with the other party BEFORE accepting an agreement.

OPTIONAL CHRIS ARBITER
Choose "Chris (StealthSwap operator)" only if both customers agree. Chris
operates this site; he is a separate third signer in the deal and must decline
his own purchases or sales. Requests appear in his authenticated arbiter desk.
No response time or acceptance is guaranteed. You receive buyer/seller invites;
the operator claims his own role. All three must accept the frozen final terms
and independently compare the escrow wallet before funding.
The site allocates a fresh public BTC key or dedicated TRON wallet to each
request. His private keys stay in his local encrypted vault. XMR uses a fresh
local wallet and the same private three-person ceremony as other arbiters.
For TRON, customers supply the dedicated arbiter's Energy/Bandwidth or TRX
separately from the escrow deposit. Keep the original customer fee-transfer
receipt: the operator's approval requires twenty confirmations of payment from
the agreed buyer or seller, or sufficient verified customer-delegated resources.
There is no platform arbitration fee, personal operator deposit, or automatic
fee charge/refund. Agree on return of unused fees and its network cost.

The tool runs LOCALLY on each participant's computer. It does not connect to
the website or send it keys. Three separate people keep their own wallets.
The website records private coordination and public wallet metadata only.
Your wallet's chain verification is required before signing any payout.

REQUIREMENTS
Node 22.18 or newer; Bitcoin Core 31.1 was tested. Use official software.
Your own synchronized Bitcoin node with RPC enabled (server=1), bound to
loopback. A pruned node is sufficient for new deals when you import the watch
descriptor BEFORE funding. Restoring old history on a pruned node may require
missing blocks. Never expose wallet RPC to the internet.

Download native-escrow-participant.mjs, its .sha256 file and LICENSES.txt.
Verify the downloaded file with Get-FileHash -Algorithm SHA256 on Windows or
sha256sum on Linux. Keep the tool, agreement and recovery record offline.

BITCOIN SETUP
1. Each buyer, seller and arbiter generates a FRESH compressed public key in
   their own Core wallet. Back up their wallet securely. In the Core console:
     getnewaddress "" "bech32"
     getaddressinfo "THE_NEW_ADDRESS"
   Share only the returned pubkey. Never upload a wallet backup, seed or key.
   Do not reuse these escrow keys in another agreement.
2. Agree on the delivery obligation, arbiter, exact BTC amount, fee budget and
   the buyer/seller payout addresses. Use distinct SegWit payout wallets.
   The mainnet deposit limit is 0.0001 to 0.001 BTC. Fee budget <= 0.0001 BTC.
   The actual network fee is deducted from the deposit, not paid by the site.
3. Create the private website workspace and copy the three one-use invites.
   Authenticate the recipient before privately sharing each role's invite.
   Download the FINAL agreement from that workspace; the earlier preview has
   a different identity. Every person independently compares its fingerprint.
4. Review locally:
     node native-escrow-participant.mjs review --terms agreement.json
   Compare the printed fingerprint, network, obligation, arbiter, amount,
   addresses and your own public key through a trusted channel, then accept
   the exact agreement in your private workspace.
5. Create a separate blank watch-only Core wallet for this deal. For example,
   in the Core console (substitute a unique local name):
     createwallet "deal-watch" true true
   Point NATIVE_BTC_RPC to the wallet you are operating. Windows examples:
     $env:NATIVE_BTC_RPC = "http://127.0.0.1:8332/wallet/deal-watch"
     $env:NATIVE_BTC_COOKIE_FILE = "$env:APPDATA\Bitcoin\.cookie"
   Signet uses its local RPC port and its signet/.cookie. Custom data dirs may
   differ. The cookie is a LOCAL credential; never paste it into the website.

COMMON FLAGS
Every wallet command requires:
  --terms agreement.json --accept-terms DIGEST --output NEW_FILE.json
Mainnet also requires --ack-mainnet DIGEST, where DIGEST is the independently
reviewed final fingerprint. The tool refuses another network or a syncing
node. Output files are exclusive-create and cannot overwrite a transcript.

FUNDING AND PAYOUT
1. btc-bind derives the three-key descriptor/address. Save binding.json.
   Paste ONLY this public result into your private workspace. All three
   people independently derive and compare it. Do not fund before they match.
2. btc-watch imports the descriptor into your watch-only wallet before funding.
3. Send the exact agreed BTC amount to the compared address. Each person runs
   btc-funding and waits for six confirmations. Extra or pending deposits
   stop payout preparation and require independent recovery review.
4. btc-plan --outcome release --fee SATOSHIS creates proposal.json; release
   pays the seller. refund pays the buyer. Fee must fit the agreed budget.
5. Switch NATIVE_BTC_RPC to your OWN signing wallet. Each chosen signer runs
   btc-sign --outcome release --input proposal.json, with a new output file.
   Each wallet independently checks the live inputs, agreed destination and
   exact fee. A dispute uses the chosen arbiter plus one buyer/seller signer.
6. Exchange the partial PSBTs PRIVATELY. Create partials.json containing:
     { "partials": ["FIRST_PSBT", "SECOND_PSBT"], "plan": ORIGINAL_PLAN }
   Switch to the watch-only wallet. Run btc-combine with that file and keep
   the resulting raw transaction BEFORE broadcasting:
     btc-combine --outcome release --input partials.json
7. Explicitly run btc-broadcast with that same reviewed file. The tool never
   automatically repeats a broadcast after a lost response. Keep the original
   raw transaction; Core decoderawtransaction can recover its txid. Inspect
   gettransaction/chain state before deciding whether another send is needed.
8. btc-confirm --txid TXID checks six confirmations. A hash alone is not a
   completed payout. Recheck after a reorg. There is no separate withdrawal:
   Bitcoin sends the deposit minus fee directly to the agreed payout address.

All commands above include COMMON FLAGS. Use --binding binding.json as well
so the local tool checks it against the independently derived descriptor.
Change --outcome to refund consistently for a refund proposal and signatures.

COORDINATION AND RECOVERY
The local report command exports public metadata only. Add --txid TXID for a
payout confirmation. Paste only that report into the private workspace.
Website participant statements are not independent chain receipts. Optional
public Bitcoin verification sends the escrow address to two public services
and records an observation at its stated time. Always verify with your node.

Download the recovery record and preserve each person's OWN encrypted wallet
backup, agreement, binding, PSBT/transaction files and signing journal. A site
outage does not remove the two-of-three spending capability. A new watch-only
wallet can use btc-watch --restore-time UNIX_SECONDS with the recovery record's
restoreTime to rescan earlier funding. It must have the relevant block history.
Never treat a failed RPC or an unconfirmed hash as a completed operation.

MONERO SETUP AND RECOVERY
Monero multisig remains experimental upstream. Functional tests do not prove
that funds cannot be stolen or become unrecoverable. Every mainnet participant
must accept this risk in the final agreement. Deposit limit: 0.01 to 0.1 XMR;
maximum fee budget 0.005 XMR, deducted from the deposit. No operator fee.
Use three FRESH independent local wallets, authenticated loopback wallet RPC
and your own matching synchronized daemon. Never reuse a funded multisig wallet
for another deal. Use stagenet/testnet with free coins for practice first.
NATIVE_XMR_WALLET_RPC,
NATIVE_XMR_DAEMON_RPC, NATIVE_XMR_RPC_USER, NATIVE_XMR_RPC_PASSWORD and optional
NATIVE_XMR_WALLET_PASSWORD configure LOCAL tools; keep them out of shared files.
An authenticated daemon also uses NATIVE_XMR_DAEMON_RPC_USER and
NATIVE_XMR_DAEMON_RPC_PASSWORD. These are separate from wallet RPC credentials.
Public-network operations refuse stale tips, missing sync metadata, target
height backlogs and bootstrap/untrusted daemon responses before wallet work.
Bitcoin also requires current headers and a recent tip after initial download;
a previously synchronized node's initial-download flag alone is insufficient.
xmr-prepare, xmr-make and xmr-exchange perform the 2-of-3 ceremony. Peer files
use {"peerInfo":["OTHER_ONE_INFO","OTHER_TWO_INFO"]}. Exchange these PRIVATELY:
they contain private view data. Only xmr-ready's public address/fingerprint
belongs in the workspace. Each person compares the final ready address.
Mainnet commands also require --ack-mainnet DIGEST and the agreement's explicit
experimentalMultisigAcknowledged flag. Keep wallet RPC off the internet.
Fund the exact agreed amount only after all three accept the terms and final
ready address. Wait for ten confirmations and unlocked outputs, exchange
xmr-sync-export/import data privately, then check xmr-funding. xmr-propose,
xmr-review, xmr-sign, xmr-submit and xmr-confirm handle the reviewed payout.
Use --binding binding.json and --outcome release/refund with COMMON FLAGS.
The public-network daemon must be online and synchronized; offline mode is
accepted only by the isolated fakechain test harness. After payout, at least
two participants independently run report with --txid and submit their public
reports confirming the same hash before the room records it. Matching reports
are participant statements, not independent verification by the website.
The persistent journal under ~/.stealthswap/native-signing-journal reserves
one proposal per wallet. Never delete its reservation to sign another payout
after a crash or lost output. Preserve the original files and arrange explicit
wallet recovery review. A crash after a signature but before a durable output
is an ambiguous signing operation: never create a replacement proposal. A
reserved operation may require manual recovery and can leave funds locked.
This tool refuses to sign again even after a wallet process is restarted.
No physical-device acceptance or independent security audit is claimed.

NATIVE TRX SETUP AND PAYOUT
This is TRX, not TRC20 USDT or a wrapped substitute. It uses a separate small
contract for EACH agreement. There is no operator contract deployment wallet,
owner, upgrade mechanism, platform fee, bond or automatic timeout refund.
The buyer, seller and chosen independent arbiter use three distinct ordinary
TRON wallet addresses. The buyer/refund and seller/payout addresses are also
their signing accounts. All three compare and accept the final fingerprint.

Customers pay to deploy their agreement and pay each transaction's Energy
and Bandwidth separately. The full deposit is credited to the recipient.
Mainnet deposit limit: 1 to 100 TRX. The agreed maxFeeBaseUnits is an ENERGY
limit per transaction, at most 100 TRX; Bandwidth can add another network fee.
Deployment may cost more than a small deposit. Review the wallet's estimate
and balance before signing. The operator does not subsidize these resources.

The private workspace supports the official TronLink browser wallet. Connect
the agreed participant account and network; never enter a private key or seed.
1. After all three accept, one buyer or seller uses Deploy my agreement. Keep
   its original transaction hash and contract address, including after a lost
   response. Never automatically deploy a replacement on an ambiguous error.
2. Wait for twenty confirmations. Each participant independently verifies the
   runtime bytecode, constructor fingerprint, three addresses and amount using
   Independently verify and confirm contract. The contract must be unfunded.
3. Only after all three bindings match, the buyer uses Fund exact deposit.
   Do NOT send an ordinary transfer to the contract address. Use its fund call.
4. Wait for twenty confirmations. Two participants approve seller payout or
   buyer refund. One approval cannot settle. A disagreement needs the other
   party plus the arbiter. Any two matching approvals can settle at any time.
5. The payee uses Withdraw my credit. Approval alone does not send TRX.
   Verify twenty confirmations and the exact full-deposit withdrawal event.
6. Keep original hashes and the public recovery record. The browser reserves
   each action before asking the wallet; it never automatically retries sending.
   An outage cannot revoke contract credit or change its fixed participants.

The local tool offers independent unsigned preparation and recovery without
the website. Set NATIVE_TRX_NODE to your chosen HTTPS TRON node if required.
The tool pins the chain genesis; selecting another network is refused.
All commands include COMMON FLAGS and --role buyer/seller/arbiter.
  trx-deploy: produces an unsigned deployment transaction and intent.
  trx-ready --binding binding.json --deployment-txid TXID: verifies a confirmed
    empty contract; binding.json contains address and termsDigest. Only the
    resulting public address/fingerprint/deployment hash belongs on the site.
  trx-build --binding binding.json --action fund/release/refund/withdraw:
    produces an exact unsigned participant call. Your own TRON wallet signs it.
  trx-review --binding binding.json --input transaction.json:
    independently validates the prepared transaction bytes, role, value,
    fee limit, contract code, chain reference and optional wallet signature.
  trx-confirm --binding binding.json --txid TXID: verifies twenty confirmations.
Never paste signed transactions or wallet credentials into the public API.
The TRX CLI does not sign or broadcast; those remain explicit wallet actions.

No third-party custody, automatic refund timer or independently audited
security claim is provided by this client. Review the program and terms.
Third-party component licenses accompany the download.