Can users bridge by themselves today
As of 2026-10-10, the updated PXA Chain website bridge is live and public activity can be viewed. Public transfer submission remains restricted to the acceptance wallet. Read the availability notice before preparing a transfer; do not send tokens directly to a bridge contract. Existing platform balances and permissions remain usable through their current interfaces.
On 2026-10-10, the website completed all four real PXT/PAT transfer paths between BNB Smart Chain and PXA using the designated wallet. Final confirmations on both chains and record recovery after refresh were checked. These acceptance results do not mean transfers are open to every wallet.
Where to transfer and view progress
- Transfer: Open the website bridge. In the upper card, choose the source network, PXT or PAT, and amount. The middle arrow reverses direction; the lower card shows the expected receiving asset. BNB Smart Chain → PXA maps PXT/PAT to wPXT/wPAT, with the reverse mapping on return. Check the recipient and availability notice before proceeding.
- Records: Disconnected visitors see “All activity”; connected wallets default to “My bridge records” and can switch to all activity. Open bridge records and select a transfer for source and destination transactions and confirmation progress. Both chains must reach the displayed requirement of 64 confirmations before final completion.
- Wallet and fees: Connect MetaMask to the website and follow network switching, token approval and transaction confirmation prompts. BSC actions require BNB; PXA returns and later on-chain actions require native PXA. Do not assume automatic fee funding. Adding PXA to MetaMask does not enable PXA in its built-in Swap/Bridge.
The page is available for viewing while unrestricted public transfer submission remains closed.
Do users need approval from three people
No. Three of five is the bridge backend's verification threshold, not an application approval process for users. Users approve tokens and deposit from their own wallet. Independent backend validators should verify source messages, automatically collect enough signatures and execute the destination transaction. Normal operation should not require contacting three administrators.
Validators collect signatures and execute destination transactions automatically. Website record queries and refresh recovery passed designated-wallet acceptance. Public error flows are still being completed; controlled success does not establish unrestricted public access.
How long does it take
A fixed number of seconds or minutes cannot be promised. Controlled mainnet observations on 2026-10-10 measured first arrival at about 37 seconds for 1 PXT and 35 seconds for 1 PAT from BNB Chain to PXA, and 4 minutes 24 seconds for 1 wPXT and 4 minutes 21 seconds for 1 wPAT returning to BNB Chain. These are differences between source and destination block timestamps, excluding approval, user confirmation and later finality waiting; chain clocks may also differ. They are individual observations, not public service guarantees or averages.
The controlled configuration waits for 64 source confirmations before execution and 64 destination confirmations before marking final completion. PXA currently produces a block about every four seconds, so one confirmation window takes roughly four minutes. Return transfers therefore generally take longer than first arrival in the forward direction. Forward arrival on PXA still requires destination confirmations afterward: arrival in 35 seconds does not mean all confirmations finished in 35 seconds. Follow actual chain progress.
Once opened, elapsed time will depend on source inclusion and confirmation, bridge message processing, and destination inclusion and confirmation. Financial wallet binding, staking and permission refresh are separate later steps. Congestion, a paused service or processing errors can extend the wait.
- 1Source transaction confirmation
- 2Bridge message processing
- 3PXA arrival confirmation
- 4Check wallet binding and staking
Steps after the bridge opens
These steps describe BNB Chain → PXA. The public entry is currently closed; this is not an available transaction flow today.
- Prepare the wallet and fees: Check PXT/PAT on BNB Chain, BNB for fees, and the PXA recipient. Later self-submitted staking or transfers on PXA also require native PXA for fees, a different asset from PXT/PAT.
- Approve the token: On first use or with insufficient allowance, approve only the required amount for the official bridge contract. PXT and PAT have separate allowances. Sufficient existing allowance may let you skip this step. Approval alone is not a bridge deposit.
- Submit the bridge deposit: Check the network, token, amount and recipient using the official entry. A normal wallet transfer to a bridge address is not a substitute for the deposit operation. Keep the source transaction hash.
- Wait for source confirmation and message execution: Confirm source success and record the message ID. The current destination minting contract only accepts execution by the bridge multisig. This check read a threshold of 3 of 5 on-chain. Controlled tests verified automatic signature collection and execution. Users do not collect signatures while waiting, but public access is still closed and immediate arrival is not guaranteed.
- Confirm arrival on PXA: Check destination transaction success, recipient and wPXT/wPAT balances, the mirror assets corresponding to PXT/PAT. If absent from the wallet display, check the correct network and official asset details before considering another action; do not deposit again.
- Check binding and stake: Match your receiving address to the financial wallet on the qualification page, then read the actual balance in staking management. Do not transfer to another operator-held account. Arrival, binding, staking and permission synchronization each need separate confirmation.
Returning to BNB Chain
After forward arrival and confirmation, switch to PXA and prepare native PXA for fees. Approve only the required wPXT or wPAT amount for the official bridge contract, then use the return entry to submit a burn, checking your BNB Chain recipient address. Approval and burn are separate wallet transactions; approval alone does not start the return. After a successful source burn, wait for source confirmations, automatic release and destination confirmations, then check the original token balance. A normal token transfer is not a substitute for burning. Do not resubmit merely because the mirror balance decreases before the original tokens arrive.
Record actual waiting time
Record approval submission/confirmation, deposit submission/confirmation, message execution, destination arrival and platform credit separately, with times and hashes. First use includes approval; sufficient existing allowance may remove that step. Separate manual multisig waiting from block production time. See the controlled measurements from 2026-10-10 above. Record first arrival and destination finality separately. Time spent on manual acceptance or repairs is not the actual transfer duration.
What counts as completion
A transaction hash only identifies a submission. A successful source debit is not full bridge completion. Check the corresponding destination transaction success and the correct network, token, recipient and balance before treating the transfer as received on PXA.
A receiving address different from the wallet bound on the qualification page can prevent the current account from using its assets. Match the account, bound address and network, then check staking and permissions. Do not send again merely because a screen has not refreshed.
Can you leave the page while waiting
Closing a browser does not cancel a broadcast transaction. The updated website queries indexed new transfers again and supports returning through a message detail link. Reconnect the same wallet for your records, or view public activity without connecting. A just-submitted source transaction may not appear until indexed. Keep its hash and message ID and do not submit again. Earlier history will be added after archive RPC integration.
What to do about a long delay
Check source success first, then the message and destination transaction. A query service failure alone does not establish a money-flow failure. Source failure, pending destination processing and destination execution failure need different handling. Avoid duplicate deposits or bridge attempts, and never share a private key.
Use feedback with the hashes, message ID and operation details for reconciliation. Recovery or refunds depend on actual state and service rules. A timeout does not imply automatic refund or immediate cancellation.
Check the current self-custody wallet flow
Production uses your own wallet bound on the qualification page. Match the receiving address, bound address and PXA network, then read the on-chain balance in staking management. No additional transfer to an operator-held deposit address is required. Platform reflection in this guide means checking binding and the chain-state read, rather than another custodial deposit. For display errors, do not transfer again; see the beginner wallet steps.
What if I have no PXA for my first transaction
A first gas grant page is now available. Check the live grant page for availability. Claims are unavailable while it shows preparation, an exhausted quota or a funding pause. Check the bridge's availability notice before transferring as well.
Once available, prepare BNB for BSC approval and deposit fees, then bridge PXT/PAT into PXA. The bridge service executes destination minting, so receiving funds does not require PXA in advance. After both chains reach 64 confirmations, connect the receiving wallet on the grant page, complete the captcha and sign a free message. You do not pay PXA gas to request or receive the grant.
The trial allows one 0.1 PXA grant per address with a balance below 0.01 PXA at request and before payout. Limits are 100 grants/day (10 PXA) and 1,000 total (100 PXA), excluding payout fees. Grants use a dedicated subsidy wallet, separate from bridge reserves. Requests are saved on the server and can be checked after refreshing. Completion requires a successful payout with 64 confirmations. The number of transactions covered depends on actual fees. Check the page for quota, funding and service availability.
The initial funded batch supports 10 requests. More requests require additional confirmed funding and an increased funded allowance, within the daily and trial ceilings.