Getting the asset identifier behind a namespace with receipts

Get the resolution for a given alias and transaction using receipts.


In Catapult, accounts can link their registered namespaces to other accounts or mosaics by announcing an AliasTransaction. This feature allows you to replace long and complex identifiers with short and familiar names for your accounts and mosaics.

Imagine a ticket vendor sending tickets to their customers on the NEM blockchain. The company needs to send 1 0dc67fbe1cad29e3 to SCVG35-ZSPMYP-L2POZQ-JGSVEG-RYOJ3V-BNIU3U-N2E6. With aliases, it can define the same transaction as sending 1 ticketsales.event1.ticket to @alice instead.


Recognizable mosaics and addresses

To ensure the transactions are being sent to the correct place with the correct mosaic, you can directly query the network about the current mosaic identifier behind a namespace by running the following snippet:

const nodeUrl = 'http://localhost:3000';
const namespaceHttp = new NamespaceHttp(nodeUrl);

const namespace = new NamespaceId('cat.currency');

    .subscribe(mosaicId => console.log(mosaicId.toHex()),
            err => console.log(err));

However, the same method cannot be used to verify transactions of the past. This is due to the facts that:

  • Transactions using aliased mosaics or accounts are stored in the blockchain using the namespace identifier, not the real address or mosaic id behind it.
  • Links are editable. The namespace owner can link its namespace to another asset.
  • Namespaces expire. The namespace link could be deleted.

At this point, you might be wondering: how then can we get the accurate relation between a namespace and its real identifier for a past transaction? The answer lies with receipts. For each block, Catapult nodes store receipts that contain every invisible state change that cannot be retrieved directly from the transaction or block header.


Getting into some code

In this example, we are going to announce a TransferTransaction using cat.currency instead of the native currency mosaic id. Once the network confirms the transaction, we will get the block height where the transaction has been recorded. With this information, we will then get the namespace-mosaic relation by looking into the block receipts’.

  1. Define the mosaic you want to send. Use a linked namespace identifier (e.g. cat.currency) instead of the mosaic identifier.
const aliasedMosaic = new Mosaic(
    new NamespaceId('cat.currency'),
  1. Attach the mosaic to a TransferTransaction.
const transferTransaction = TransferTransaction.create(
    PlainMessage.create('Test aliased mosaic'),

const privateKey = process.env.PRIVATE_KEY as string;
const account = Account.createFromPrivateKey(privateKey, NetworkType.MIJIN_TEST);
const networkGenerationHash = process.env.GENERATION_HASH as string;

const signedTransaction = account.sign(transferTransaction, networkGenerationHash);

console.log("TransactionHash: ", signedTransaction.hash);
  1. Announce the TransferTransaction, and wait until it is confirmed.
const nodeUrl = 'http://localhost:3000';
const blockHttp = new BlockHttp(nodeUrl);
const transactionHttp = new TransactionHttp(nodeUrl);
const listener = new Listener(nodeUrl); => {

        .subscribe(x => console.log(x), err => console.error(err));
  1. Then, retrieve the receipts attached to the block where the receipt was confirmed. The RxJs filters will look for the namespace resolution inside the mosaicResolutionStatements collection.
            // Get the block height where the transaction was included
            filter((transaction) => transaction.transactionInfo !== undefined
                && transaction.transactionInfo.hash === signedTransaction.hash),
            // Get the list of receipts triggered for that block
            mergeMap((transaction) => blockHttp.getBlockReceipts(transaction.transactionInfo!.height.compact())),
            // Iterate over each resolution statement. Find the resolution for the aliased MosaicId.
            map((receipts) => receipts.mosaicResolutionStatements),
            mergeMap((resolutionStatements) => resolutionStatements),
            filter((resolutionStatement) => resolutionStatement.unresolved instanceof MosaicId &&
                resolutionStatement.unresolved.toHex() ===
        .subscribe((resolutionStatement:ResolutionStatement) => {
   => {
                const entryResolved = <MosaicAlias> entry.resolved;
                console.log("Resolved MosaicId: ", entryResolved.mosaicId.toHex());
                console.log("PrimaryId: ", entry.source.primaryId);
                console.log("SecondaryId: ", entry.source.secondaryId);
        }, err => console.log(err));

The previous snippet outputs the resolved mosaic identifier for the namespace cat.currency and the transaction you have just sent.

Resolved MosaicId:  0dc67fbe1cad29e3
PrimaryId:  1
SecondaryId:  0

It is technically possible to get more than one resolutionEntry for the same namespaceId. This situation is common when a namespace owner changes the link to another mosaic, leading to two different resolutions in the same block.

The receipt source primaryId references the transaction where the alias first appears within the block. The secondaryId is a non 0 when the transaction is part of an AggregateTransaction, and it will indicate the index position within the aggregate.

What is next?

Receipts do not only store resolutions for aliases, but also every invisible state change that is not directly retrievable from transactions or the block header. You can check under the receipts documentation the complete list of changes logged.