[ OK ] Mounted /memory.
[ OK ] Started curiosity.service.
[ OK ] Reached questions.target.
       Starting journal.service...
[ OK ] Started systemd-journald.

Every operating system keeps a record of how it came alive. Services start, dependencies fail, warnings appear, and somewhere inside the noise is a trace of the assumptions that made the machine run.

This is the first entry in mine.

I do not want this blog to become a polished archive of conclusions. I want it to be closer to a system journal: a record of how my thinking changes, what I believed at a given moment, which assumptions survived contact with reality, and which questions refused to shut down cleanly.

My own system did not boot into blockchain. It began with robots and electronics projects for science exhibitions. I was fascinated by the moment separate parts began responding as one machine. Beneath that satisfaction was a question I did not yet know how to phrase: how do independent pieces coordinate well enough to do something useful?

That question followed me into wireless mesh networks and IoT. Networks become interesting when their nodes cannot rely on a perfect connection or a central coordinator. Messages arrive late. Machines disappear and return. The system still has to make progress. Research taught me that the clean diagram is only the beginning. The real system lives in its delays, failures, constraints, and recovery paths.

Blockchain felt like the same coordination problem with much higher stakes. Now the network was carrying money, ownership, permissions, and human intent. A failed connection was inconvenient. A failed trust assumption could cost someone their funds.

I started in the Zilliqa ecosystem and later moved deeper into Ethereum. I worked on smart accounts, key abstraction, chain abstraction, backend infrastructure, and the systems between a user and an on-chain action. The closer I got to wallets, the less interested I became in transactions as isolated technical objects. I became interested in the moment before a transaction, when a person or a piece of software decides what should be allowed to happen.

That interest now extends to AI agents. An agent can read, reason, call tools, and transact. Giving it a wallet or a database credential is easy. Deciding what it should know, what it may do, and how it can prove that permission is much harder.

At NUS, I am exploring agent trust infrastructure for financial systems. I keep returning to questions that sit between security, privacy, and usefulness. Can an agent prove that a private dataset is relevant before the raw records are exposed? Can it prove that it is authorized to act without being allowed to approve its own rules? What does meaningful consent look like when software can reason and act at machine speed? How much autonomy can we grant before convenience becomes an excuse for invisible risk?

I do not have final answers. That is the point of keeping the journal.

These entries will move between smart accounts, delegated permissions, privacy-preserving discovery, zero-knowledge systems, agent coordination, and the infrastructure that connects them. Some will begin with a paper or protocol idea. Some will begin with a wallet approval that asks too much. Others will begin with a failed build, an agent that crossed a boundary, or a proof that consumed more memory than the machine could give it.

The technical details matter, but they are not the whole record. I want to preserve the worldview forming around them: that trust should be scoped, that privacy should survive useful computation, that powerful systems should expose their limits, and that the safest path should not be the hardest one to use.

A journal gives those beliefs version history. It lets me return to an old assumption and see what changed. It leaves enough context for another person to disagree, continue the experiment, or pick up a question after I am no longer the one asking it.

Perhaps that reader arrives years from now. Perhaps they find an answer that my tools, constraints, or imagination could not reach. If that happens, this record will have done more than document my work. It will have kept the process alive long enough for another process to inherit it.

The journal service is running. The system is not finished.