Reservation-based Model

A bridge connects the local blockchain to a remote blockchain. pDiem follows the “reservation asset” cross-chain asset transferring pattern (see the equivalent pattern defined in XCM Format). In our case, pDiem (and its parachain) is the local blockchain, and Diem is the remote blockchain.

The pDiem bridge controls a set of sovereign accounts (see XCM Format - Definitions) on the Diem side, which hold all the Diem assets transferred to pDiem side. The pDiem Contract has a builtin ledger to store the owner of the Diem assets in the sovereign accounts.


When a user transfer some Diem assets to Polkadot side, he first sends the assets to his deposit address generated by the pDiem Contract (thus a sovereign account), denoted by a deposit transaction. Then one or more pDiem Relayers relay the deposit transaction as well as the sufficient cryptographic proof to the pDiem Contract. The contract validates the deposit transaction it receives, and add the corresponding amount to the ledger.


The pDiem ledger exposes a series of p-tokens on the parachain side (pXUS to XUS on Diem), which can be transferred between Polkadot accounts as any typical token. The pDiem contract also follows the Polkadot XCM token standard. So it can be transferred between any parachain that accepts standard XCM assets.

Currently Diem has a builtin native token XUS, but its design supports multiple tokens. When multiple tokens exist, pDiem can accept any number of different tokens, and the ledger in the pDiem Contract will reflect all the assets in the reservation correspondingly.


When a user wants to withdraw pXUS back to the Diem blockchain, he sends a request to the pDiem Contract. The contract will burn the token, and sign a Diem transaction to unlock the token from the sovereign account to the withdraw account. The transaction will be broadcasted by the relayers, and take effect once confirmed by the Diem blockchain.

Edit this page on GitHub