Mar 2026 The Symbol Syndicate | Anthony’s Engineering Blog

Read the March 2026 blog here

https://thesymbolsyndicate.notion.site/March-2026-3a9a7f7eb5e480928273c87fc59f418f

March 2026 Anthony’s Engineering Blog (Japanese Translation)

First of all, congratulations to all the winners of the Hack+ 2026 event 🎉. If you did not place in the hackathon, do not be discouraged. You must have gained something valuable from the experience. Keep going and keep doing your best!

March felt like a month when several things finally started coming together. Most of the development work continued to focus on the NEM Explorer backend. I finally completed the namespace module and began work on the schemas for the mosaic and transaction databases. There is still a lot to do, but the backend is gradually taking shape.

It was also an exciting month with the release of GPT-5.4. AI is becoming increasingly intelligent and feature-rich. I have been spending most of my time researching and exploring its improvements and how to use it in my development workflow.

Summary of Main Work

Completed and merged development of the namespace module
Started development of the mosaic module
Redesigned the transaction database schema
Refactored REST API tests and reduced code duplication

Details of Each Task

Namespace module

Completed the workflow to extract namespace registration information from blocks and save root namespace, subnamespace, ownership, and expiration details in the database.
Added the /namespace/<name> and /namespaces endpoints so the frontend can query individual root namespaces and subnamespaces and retrieve a paginated list of namespaces.
Addressed feedback and merged the changes.

Mosaic module

Completed processing of mosaic definition and mosaic supply change transactions during block processing.
Added the /mosaic/<namespace>, /mosaics, and /mosaic/rich/list endpoints.
Created a PR. It is currently waiting for team review.

Transaction schema redesign

In the initial design, different transaction types were stored in separate normalized tables. While this looked neat, retrieving all transactions required too many joins and could negatively affect performance.
Therefore, I decided to switch to a single transaction table that can store all supported transaction types. The schema design is complete, and I have started implementing the processing logic for each type.

Unit test refactoring

The unit tests passed and the code had sufficient test coverage, but improving maintainability was also important, so I refactored the REST API tests by extracting repeated pagination, sorting, and missing-data checks into reusable helper functions.

What’s Next

The namespace module development is complete and has been merged, while the mosaic module is currently waiting for team review. In the meantime, I will continue implementing transaction processing for each transaction type using the new single-table design. This is quite a lot of work, but it should provide a simpler and more efficient foundation for Explorer’s transaction queries.

Thank you for reading this far. See you again next time! 🏴‍☠️

—

Anthony (Japanese translation by Radio)