Import

[Source]

(Added by the [Import amendment][].)

Example

This example shows the outer fields for a first B2M Import that creates an account. Blob is a placeholder, not a valid proof. Export callbacks require an existing account and use its current Sequence; the example’s zero Sequence and Fee do not apply to them.

{
  "TransactionType": "Import",
  "Sequence": 0,
  "Fee": "0",
  "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
  "Blob" : "DEADBEEF"
}

Fields

Field	JSON Type	Internal Type	Description
Blob	String	Blob	Hex value representing an XPOP
Issuer	String	AccountID	(Optional) Address that can be used inside the Hook.

Error Cases

• If the account is Non Activated then the Sequence must be 0 and the Fee must also be 0
• If the account is Activated then the Sequence and the Fee are calculated using the standard method.
• If the Issuer field is present then the Fee must be calculated using the standard method.
• An account-authorized Export callback without its matching ExportLatch returns telEXPORT_LATCH_REQUIRED without applying. An allowance-only attempt with an absent or ineligible grant instead fails account authorization, typically with tefBAD_AUTH, without a fee claim.

Export Callbacks

An inner XPOP transaction with TicketSequence selects the Export callback path. On that path, the canonical final xahau/export Memo is mandatory, and its source Export transaction hash W identifies an ExportLatch keyed by (Account, W). An inner transaction that uses Sequence instead follows the burn-to-mint path; adding an Export Memo does not change that discriminator.

Import projects the release-stamped target transaction back to its canonical identity form and verifies the latch’s normalized intent digest. Different destination-valid signer subsets for the same intent can therefore complete the callback even though they have different target transaction IDs. Import still verifies the XPOP, validator-list freshness, and target-ledger finality before Hooks run.

The signature witness is not a prerequisite for callback execution. An assembler can use the post-validation signature stream and return XPOP before the on-ledger witness appears. In that order, Import records XPOP arrival on the latch; the later witness erases the latch and releases its reserve. If the witness arrived first, Import is the second fact and performs the erase.

Stopping Export publication retains callback readiness. Explicitly erasing the latch with tfExportEraseLatch forfeits it: a later account-authorized callback returns telEXPORT_LATCH_REQUIRED, while allowance-only delivery fails account authorization. Neither operation revokes signatures already published.

Callback Authorization and Fees

The outer Import Account must be the proven target account and source latch owner. By default its enabled master key, current regular key or configured multisigning quorum must authorize the Import. Possession of an XPOP alone is insufficient.

If the original Export intent included a positive native ExportCallbackFee, anyone may assemble and submit a signatureless Import containing the exact eligible callback. The carrier needs no key or ledger account: authority comes from the original intent’s grant and the verified proof. The outer Account names the owner, and Fee must equal the stored amount: neither lower nor higher is accepted through this permission. A normally account-authorized Import may choose a different Fee, subject to ordinary fee rules. The owner pays from its balance at callback time; the relayer receives no reward.

The signatureless envelope requires SigningPubKey: "" and absent TxnSignature and Signers. The remaining permitted fields are TransactionType, Account, Sequence, Fee, Blob, Flags (only tfFullyCanonicalSig), NetworkID, LastLedgerSequence and AccountTxnID. Extra owner-side instructions such as Issuer, HookParameters, HookName, SourceTag and Memos require ordinary account authorization. All existing proof, domain, origin, digest, latch and validator-list checks still apply. Adding an unrelated signature does not grant account authority or qualify for the signatureless path.

For an opted-in latch, the assembled outer transaction has this shape. Replace the placeholders, use the owner’s current source Sequence and the exact latch fee, and follow the source network’s NetworkID rules:

{
  "TransactionType": "Import",
  "Account": "rOwner...",
  "Sequence": 123,
  "Fee": "100000",
  "NetworkID": 21337,
  "SigningPubKey": "",
  "Blob": "[VALID_XPOP_HEX]"
}

Serialize and submit this transaction through submit using tx_blob; no carrier signature or signing secret is supplied. The XPOP still contains the target transaction and validation signatures needed to prove execution. This signatureless path does not apply to B2M or account creation.

A successful delivery consumes the callback permission. A duplicate cannot authorize another debit, whether the latch was erased or remains with lsfExportXpopSeen. Hook rejection or a later apply failure does not authorize a fee-only debit for an allowance-only callback; account-authorized Imports retain ordinary fee/error behavior. An absent, spent, mismatched or otherwise ineligible allowance normally returns the account-authorization error rather than the owner-authorized retry/duplicate result.

Sequence and Replay Protection

There are two separate sequences in a B2M Import: the outer Xahau transaction uses normal account sequencing after account creation, while ImportSequence on the account tracks the proven target transaction’s Sequence to reject repeated imports. Outer Sequence: 0 is a bootstrap exception for an absent account, not a general third-party delivery mechanism.

Export callbacks use their exact (Account, W) latch for proof replay protection, but the outer Import still uses and consumes the owner’s current source Sequence. Third-party callbacks cannot consume source Tickets. Ordinary account-authorized Imports retain normal Sequence/Ticket choice. Multiple callbacks or owner transactions can therefore contend for the same source Sequence.

A latch-backed Sequence-0 callback lane is not implemented. A fixed ExportCallbackFee and signatureless outer envelope also do not establish one transaction ID for every equivalent proof: source Sequence, permitted outer fields and proof representations may still vary. Full canonicality, repeated-work suppression across differing envelopes and sequence-free delivery remain follow-up design work; clients must not assume those properties.

Notes

It is recommended that if you use a SignerList or RegularKey to sign your transactions that you key your accounts FIRST before attempting to B2M XAH .

• If the inner (xpop) transaction is AccountSet the mainet existing flags will be transfered to the new network.
• If the inner (xpop) transaction is SetRegularKey with the RegularKey field omitted or empty, and a signers list does not exist for the account then the lsfDisableMaster flag will be set on the account.
• If the inner (xpop) transaction is SetRegularKey then the lsfPasswordSpent flag will be set on the account.
• Distinguish a source Ticket on the outer Import from the proven target transaction’s TicketSequence, which selects the Export callback path. Allowance-only callbacks cannot use a source Ticket.

Importing for the Issuer

For issuers, there are additional steps to follow before their asset holders can import transactions.

Firstly, issuers need to install a hook. There are two options for this: B2MNFToken or B2MPayment.

B2MNFToken

A NFTokenBurn transaction on mainnet will result in a URITokenMint transaction on the network.

c hook: https://example.com

B2MPayment

A Payment transaction on mainnet to the Issuer will result in a Payment transaction from the Issuer on the network.

c hook: https://example.com

Please note that the process of importing for the issuer involves specific transaction types and requires careful configuration. Always ensure that the hooks are correctly set up and that the transactions are valid for the intended operations.