Q1: What is the story behind MarsCat?

The story behind MarsCat really begins with what I’ve spent most of my career watching from the inside.

I started out in Singapore in 1999, founding and running my own media advertising agency for six years. The clients I served were the financial institutions of the region — American Express, Standard Chartered, HSBC — and that early seat, on the agency side selling to banks, gave me an unusually direct view of how customer data flows between brand, channel, and operator long before “data” became the public conversation it is today. From there I moved inside the banks themselves, spending close to a decade running consumer credit and distribution businesses across Asia-Pacific at American Express, HSBC, and ABN AMRO, across Singapore, Hong Kong, and the wider region. In parallel and afterwards, I served for several years as Executive Vice Chairman of ATAS Aeronautik, where I worked inside another industry — aviation — that, like banking, operates on the assumption that user trust has to be carefully engineered into the system rather than left to good intentions.

Those worlds look very different on the surface, but they share a common reality: the user hands their identity and data to an operator, the operator takes on the responsibility of protecting it, and the asymmetry sitting between the two is simply treated as a cost of doing business in the modern economy.

The longer I sat across those seats — agency, bank, aviation, board — the more I came to believe that arrangement, however well-managed by any individual operator, was approaching the limits of what it could reasonably ask of users. The missing piece wasn’t better policies or more responsible operators. It was a different architecture. Privacy can’t be a promise made by the institution holding your data. It has to be a property of the system itself.

MarsCat is that system. It’s a privacy-first Web3 runtime, an all-in-one app for wallet, social, finance, media, and gaming — but with no account to register, no identity to hand over, and cryptographic keys that live only on the user’s own device. The platform can’t betray the user, because there’s nothing for it to betray. Communication runs over a decentralized peer-to-peer network with end-to-end encryption and post-quantum-resistant cryptography, so privacy isn’t a feature we offer — it’s the default condition of being on the network.

As for the name — we wanted Mars: open ground the incumbents haven’t claimed yet. And we wanted the way a cat moves through it: quietly, on its own terms, leaving no trail.

Q2: What experience does the MarsCat team have in Web3?

“Web3 experience” is one of those phrases worth slowing down on, because the honest answer depends on what kind of Web3 product you’re trying to build.

If the question is whether our engineering core has shipped serious decentralized infrastructure, the answer is yes. The team behind MarsCat designed and deployed the underlying network ourselves — a peer-to-peer runtime with its own communication protocol, end-to-end encryption layered with post-quantum-resistant cryptography, and a multi-protocol stack covering relay networking, serverless application deployment, encrypted storage, anonymous identity, and service concealment. The platform you see today — wallet, social, finance, media, gaming, all inside a single app — runs on infrastructure we built ourselves, not on someone else’s stack we wrapped a layer around.

If the question is what the leadership brings to a Web3 project specifically, my own answer is less conventional. Most Web3 founders come up through crypto-native channels. I came up through the systems crypto is supposed to replace — first founding and running my own media agency in Singapore, serving exactly the financial institutions I would later join; then two decades inside global banks running consumer credit and distribution across Asia-Pacific; and in parallel, years of board-level work at ATAS Aeronautik in aviation, an industry whose entire business depends on engineering trust into systems that can’t afford to fail. That sequence — agency selling into banking, inside banking running the business, then into a separate high-trust industry at the board level — teaches you things crypto-native teams sometimes underestimate. How trust infrastructure actually gets used at scale. What a compliance failure really costs. How distribution works in regulated markets. Why most users never read the technology — they read the experience.

That combination is the bet. Cryptography and protocol design from people who’ve lived inside decentralized systems, paired with operating instincts from people who’ve lived inside the regulated, high-trust industries Web3 is rebuilding. A privacy-first platform that ever wants to be used by anyone outside the crypto crowd, in our view, needs both.

Q3: Why did you choose to build a privacy-first platform?

Because privacy is the one thing in digital life that, once you lose it, you cannot get back — and the architecture underneath almost every platform built in the last twenty years has been quietly accumulating more of your data than anyone can ever give back to you. I didn’t arrive at this view as an ideologue. I arrived at it as an operator who spent over two decades building businesses inside well-run institutions doing their work properly.

The earliest version of this view came from my six years running a media agency in Singapore, with financial institutions among my largest clients. From that vantage point — across brand, channel, and operator — you see early how much of the modern economy quietly depends on user data moving across many links in a chain, even when every link in that chain is operating responsibly.

The view sharpened during my years inside the banks themselves — American Express, HSBC, ABN AMRO. These were institutions that took data protection extremely seriously: robust frameworks, serious compliance, careful people. And precisely because of that, what became clear to me was how much data any modern financial business has to gather simply to function, and how much responsibility has to be carried on the operator’s side of the relationship to keep that data safe. The frameworks were real and the work was diligent. None of that changes the underlying structural fact: in any centralized arrangement, the volume of data that accumulates on the institution’s side, and the volume of exposure that accumulates on the user’s side, only ever grow.

My years on the board of ATAS Aeronautik reinforced the same instinct from a completely different angle. Aviation is an industry where the consequences of a system failure are immediate and severe, so the entire industry has been pushed, over decades, to design failure tolerance into the structure of operations themselves — not to rely on individuals or institutions being unfailingly careful. That principle — engineer the safety property into the architecture, don’t ask the operator to perform it indefinitely — is the same principle that, in my view, digital privacy needs to adopt.

The shift in my thinking came from realizing that this is not a problem you can solve by behaving better inside the old architecture. You can write stronger policies, hire better compliance teams, run more audits — and you’ll still end up holding data that, on a long enough timeline, faces leaks, regulatory disclosure obligations, third-party access, or simply uses no one originally anticipated. The only durable solution is to design a system where the operator never holds the sensitive data to begin with.

That’s what privacy-first means for us. Not encryption bolted onto a conventional platform. Not a privacy mode the user has to remember to switch on. A runtime where identity is a key generated on the user’s device, where communication is peer-to-peer and end-to-end encrypted by default, where the network itself has no central vantage point from which anyone — including us — could surveil it.

And the timing matters. We’re entering an era where AI makes data extraction cheaper, more automated, and far more invasive than anything the last decade prepared users for. Building anything other than a privacy-first platform, at this moment, would feel to me like building a house with no doors and trusting that no one will walk in.

Q4: What makes MarsCat different from other Web3 privacy projects?

Most privacy projects in Web3, when you look at them closely, are really privacy features. A private transaction layer on top of a public chain. An anonymous messaging app that lives alongside your regular wallet. A mixer, a zero-knowledge module, a single-purpose tool that hardens one slice of the user’s digital life while everything around it remains exposed. They are useful, and we respect the work — but they treat privacy as something the user reaches for in specific moments, rather than the environment they live in.

MarsCat is different in three ways that matter, and each of them traces back to something I’ve seen up close in earlier parts of my career.

The first is scope. We are not a privacy feature attached to a product. We are a privacy-first runtime that the products run on. Inside a single app, the user gets wallet, social, finance, media, and gaming — and the same privacy guarantees apply uniformly across all of them, because they all share the same underlying network, the same encrypted communication layer, the same local-key identity model. The user doesn’t have to assemble privacy out of five different tools. That instinct comes directly from my years in retail financial services — at American Express, HSBC, ABN AMRO. The customers who actually used those products didn’t want a credit card, a loan, a payment channel, and a rewards program as four separate experiences; they wanted one relationship that worked. Privacy is no different. If it’s fragmented across tools, most users will simply give up and default to the unsafe path. MarsCat is built so the user doesn’t have to.

The second is the architecture itself. A lot of Web3 privacy projects still rely on centralized servers somewhere in the stack — for relays, for indexing, for app distribution — which means the privacy guarantee ultimately depends on trusting that operator. Our network is peer-to-peer end to end, built on a dual-node design where relay nodes carry encrypted traffic and application nodes can run on anything from a server to a phone. There is no central point from which traffic can be intercepted, profiled, or shut down, including by us. Combined with end-to-end encryption and post-quantum-resistant cryptography, privacy isn’t a policy we enforce — it’s a property of the network we couldn’t violate even if we wanted to. The conviction behind this design comes from the same place as the work I did at the board level of ATAS Aeronautik in aviation: in any high-consequence industry, you eventually learn that the only safety property worth depending on is the one engineered into the structure of the system. Anything else — anything that depends on every operator behaving correctly, under every condition, indefinitely — is asking the user to carry a kind of trust no one can really verify. The only durable design is one where the architecture itself doesn’t require that trust.

The third is intent. A lot of privacy projects are built for users who are already convinced — people who arrive looking for anonymity and know exactly what they want to do with it. We’re building for the much larger group that hasn’t arrived yet: ordinary users who want a wallet, a social feed, a way to send value, a place to play — and who shouldn’t have to become cryptographers to be safe. The whole product is designed so that the strongest version of privacy is also the easiest path through the app. This bar comes from the earliest years of my career, running my own media agency in Singapore — six years of watching how mass-market audiences actually choose between paths. The lesson there was unambiguous: in any consumer-facing category, the path with the lowest friction wins. If the better option is harder to use than the worse option, the worse option wins every time. We’ve taken that seriously as a design constraint, not a slogan.

Put those three together — full-stack scope, genuinely decentralized architecture, and a design bar set at mainstream usability — and that’s the space MarsCat occupies that most other privacy projects, by their own choice of scope, don’t.

Q5: What is the next major milestone for MarsCat?

The hardest part of building infrastructure is largely behind us — the network is live, the runtime is shipping, and the all-in-one app already covers wallet, social, finance, media, and gaming on a single privacy layer. The next milestone is no longer about proving the technology. It’s about distribution — and that’s a problem I’ve spent most of my career solving in other industries.

Concretely, the next phase breaks into three tracks.

The first is users. Up to now, our focus has been on engineering integrity. The next phase is a deliberate push to put MarsCat into the hands of mainstream Web3 users, and then — more importantly — users who are not yet in Web3 at all. This is the part where my own background matters operationally. I spent close to two decades distributing consumer financial products across Asia-Pacific — credit cards at American Express, unsecured lending at HSBC, external sales channels at ABN AMRO across Hong Kong and the broader region. Those products didn’t sell themselves on technical merit either; they reached people through channel design, partnerships, and on-the-ground market structure. That’s the playbook I’m bringing to MarsCat’s user-side rollout, starting in Asia-Pacific where the network and the relationships are strongest.

The second is developers. MarsCat isn’t just a consumer app — it’s a runtime, and the long-term value of a runtime is the ecosystem on top of it. The next milestone there is opening the platform properly to third-party developers, so they can deploy privacy-native applications onto our network with zero-cost deployment, no central server dependency, and the same guarantees our own app runs on. I’ve lived a version of this transition before — at U ZAPP Solutions, my work with Fuji Xerox was precisely about moving enterprise customers from standalone hardware into integrated software-and-subscription ecosystems. The categories are different, but the underlying motion — taking a closed product and turning it into a platform others build on — is one I’ve operated through end-to-end.

The third is capital and partnerships. I’m leading our fundraising work personally, engaging technology-focused investment funds and strategic partners. This is where the combination of sides of the table I’ve sat on becomes most useful. Two decades inside global banks gave me a working understanding of how capital allocators actually think about risk, compliance, and regulated markets — and the years I spent founding and running my own business in Singapore, as well as my long-running role on the board of ATAS Aeronautik, gave me the operator side of the same equation. For a project of this stage, the priority isn’t volume of capital; it’s bringing in partners who understand that we’re not building a feature inside someone else’s market, we’re opening a new category — and that requires conviction from the people backing it.

If I had to compress the whole next phase into one sentence: we’ve finished proving this can be built, and we’re now proving it can be lived in — and that second proof is the part of the work my career has actually been preparing me for.