Forem: Ko Takahashi

Two 'we trust you' partnerships arrived as our design matured. Here's what changed in our technical decisions.

Ko Takahashi — Wed, 06 May 2026 11:01:04 +0000

A short build-in-public note from the week.

For most of Matsuri's existence I told myself: be ready to build alone, at first. In early-stage work, that vow is the right default — pitch-and-crowd-rushes-in usually means the business isn't real.

This week, two unexpected partnership inquiries arrived at the same time:

One of Japan's largest event organizers — about partnering for our June real-operations period.
A well-known overseas Web3 security & smart contract audit firm — about an audit partnership, inbound (not solicited).

Names withheld until contracts close. The timing matters: Matsuri's web version had just landed and we're heading into June real operations. Months of design and architectural decisions had just become visible in shippable form. That's the moment these two inquiries showed up.

Genuinely happy. Also responsibility-heavy. Below is what technically changes when partnerships arrive at this kind of phase.

What changes when partnerships arrive at design-maturity

Two failure modes are tempting and wrong.

❌ Failure mode 1: over-engineering for the partner you imagine

The instinct is: 'a big event organizer is coming, so let's build enterprise-grade capacity now.' This guarantees you miss your June ship date and burn the trust that just arrived.

What we actually scoped:

Minimum capacity needed for early June operations.
Harden only the surfaces the audit firm will gate on.
Everywhere else: design extension points so the next layer of hardening doesn't require a rewrite.

❌ Failure mode 2: hard-coding a single partner's requirements

A partner-specific code path inside core logic is technical debt the moment a second partner arrives.

// ❌ Don't
function processEvent(e: Event) {
  if (e.organizer === 'PARTNER_X') { /* special path */ }
}

// ✅ Externalize as profile
type OrganizerProfile = {
  scaleHints: ScaleHints;
  customizations: Customization[];
};
function processEvent(e: Event, profile: OrganizerProfile) { ... }

Requirements live as profiles, not branches.

What 'audit-ready' actually demands

Receiving an audit partnership inbound — when the firm reaches out before you do — is also a quiet vote of confidence in the architecture itself. It's flattering until you sit down to scope what 'audit-ready' actually means in practice. For us it meant going back and:

Writing the threat model in something humans can read, not just in code.
Listing the invariants the contract is expected to preserve.
Raising test coverage to a number we can defend in a meeting, not just in a CI badge.
Documenting the boundary between on-chain and off-chain logic, including failure modes both sides need to handle.

type AuditReadiness = {
  threatModel: 'documented';
  invariants: Invariant[];
  testCoverage: number;       // %
  formalSpec: 'present' | 'absent';
  auditTrail: 'append-only logs';
};

None of this is glamorous. All of it is what a serious auditor expects to find before opening the editor.

What changed inside

The vow to build alone didn't disappear. The accumulating fact of not being alone now sits next to it. Each is a real input to daily decisions.

What shifted is mostly responsibility, not relief. Someone deciding we'll be early with this team creates a quiet enforcement that doesn't come from outside. You can't betray it.

In June, real operations begin. That phrase means something starts moving — and also I begin returning what was placed in my custody. It feels less like 'now we begin' and more like 'the prerequisites are finally in place.'

What I'd love to hear

If you've received an early-stage partnership inquiry as your design or release was maturing: what changed in your technical roadmap the day after?
If you've audited or been audited: what's the single thing you wish founders prepared before you opened the codebase?

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. ko-takahashi.jp · matsuri.group · j-times.org

We're shipping audit-first, federated overseas chapters for our community economy platform. Here's the architecture.

Ko Takahashi — Mon, 04 May 2026 21:09:24 +0000

A build-in-public note on the participation architecture for Matsuri Platform — overseas expansion as federated cultural chapters with audit as a hard precondition.

Two design choices, one philosophy

Matsuri is an architecture for community-owned economic zones — first implemented through Japanese festival culture, designed to stand parallel with any culture.

Going global makes two structural choices unavoidable:

Federated overseas chapters, not centralized branches.
Audit as a hard precondition, not a 'nice to have.'

Both ship into design before June real operations.

1. Federated parallel chapters

NOT: HQ → branches (centralized control)
YES: Shared core ← multiple parallel chapters (local governance)

shared core platform
  ├── Matsuri JP   ← Japanese community runs it on Japanese terms
  ├── Matsuri TW   ← Taiwanese community runs it on Taiwanese terms
  ├── Matsuri BR   ← Brazilian community runs it on Brazilian terms
  └── Matsuri NY   ← NY Japanese diaspora runs it on local terms

In types:

type CulturalContext = {
  region: string;
  governance: GovernanceRules;       // local
  paymentRails: PaymentRails;        // local
  contentNorms: ContentNorms;        // local
  operatingRules: OperatingRules;    // local
};

type CorePlatform = {
  liveStream: LiveStreamStack;       // shared
  walletAbstraction: WalletAPI;      // shared
  liveableModel: LiveableSchema;     // shared
  trustPrimitives: TrustPrimitives;  // shared
};

type RegionalMatsuri = {
  context: CulturalContext;
  core: CorePlatform;
};

HQ does not 'supervise' a Taiwanese chapter. Cannot, and should not.

2. Audit as precondition

A recent inbound partnership inquiry from a major overseas Web3 security & smart contract audit firm reframed the timeline. Audit is not a 'nice to have' in Web3 — it is the line where its absence is fatal.

For June, the design is being re-done with audit as a hard constraint:

Invariants documented

interface MatsuriInvariants {
  totalMintedSupply: bigint;          // doesn't grow; only circulates
  pledgeIntegrity: 'pledged <= goal'; // no over-funding
  ticketUnique: 'no double-spend';
  organizerConsent: 'mandatory for cancellation';
  refundPath: 'always available within window';
  jurisdictionAware: 'compliance checks per region';
  fxRateLockedAtPledge: 'no slippage on fulfillment';
}

Threat model documented

Organizer-side malice: fake events, post-crowdfund disappearance.
Audience-side malice: ticket scalping, impersonation, review brigading.
Platform-internal malice: admin privilege abuse.
Cross-border specific: FX exploitation, local-law evasion.

Mitigations documented per threat. Auditor-friendly format from day one.

Boundary made auditable

type BoundaryContract = {
  onChain: {
    valueTransfers: 'tracked on chain';
    invariantChecks: 'enforced by contract';
    publicEvents: 'append-only logs';
  };
  offChain: {
    userIdentity: 'KYC, regional compliance';
    contentModeration: 'human + AI';
    customerSupport: 'human';
  };
  bridge: {
    eventEmission: 'on-chain emits → off-chain consumes';
    settlementHooks: 'off-chain triggers → on-chain settles';
  };
};

Unclear boundaries make audits impossible. Built into the spec from the start.

Cross-border hooks (kept out of core)

type CrossBorderHook = {
  fxLockAt: 'pledge time, not fulfillment';
  jurisdictionGate: (user: User, action: Action) => boolean;
  localCompliance: ComplianceChecks;
  refundCurrency: 'always pledger currency';
};

These live on the regional chapter, not core. Keeps the core auditable; lets regions specialize.

What this means for who's reading

Web3 audit / security folks: multiple audit rounds incoming. Early conversations welcome.
Overseas community / business operators: regional launch partner entry exists.
Devs working on cross-border DAO / Web3 commerce: would love comparative notes.

Discussion

If you've shipped cross-border / multi-jurisdiction Web3 systems, what's the boundary you most regret leaving fuzzy?
For audit-first design — what artifact (threat model, invariants, traceability) made the biggest difference for your auditor?

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. ko-takahashi.jp · matsuri.group · j-times.org

We shipped 3 features in one flow today: Shop + Crowdfunding + Live. Here's the integration design.

Ko Takahashi — Mon, 04 May 2026 06:23:42 +0000

A short build-in-public note from today.

We finished shipping the web implementation of Matsuri Platform. Three features now operate as a single integrated flow on the web:

Shop (marketplace)
Crowdfunding
Live Streaming that runs across both — and across in-person events

This post is the design retro, not the press release.

The integration target

Watching a stream → wanting the product → buying it → backing the maker's next project. That arc is one human behavior. In today's tooling it's split across three apps with three identities, three payment flows, and three reputation systems.

We collapsed that.

A shop seller can broadcast live while selling their products.
A crowdfunding creator can show progress live while gathering support.
An event organizer can run on-site logistics and live operations through the same flow.
Audiences move freely between watching, supporting, buying, and broadcasting.

1. Data model: `Liveable` as a first-class union

We didn't model 'a stream' as the unit. We modeled what flowed through a stream.

type Liveable =
  | { kind: 'shop_item'; itemId: string; price: Money }
  | { kind: 'crowdfund_project'; projectId: string; goal: Money; raised: Money }
  | { kind: 'event'; eventId: string; venue?: Venue };

type LiveSession = {
  hostUserId: string;
  startedAt: DateTime;
  status: 'preparing' | 'live' | 'ended';
  attachedLiveables: Liveable[];   // multiple sellable things per session
  metrics: {
    concurrentViewers: number;
    totalGmv: Money;               // money that moved during the stream
    pledgesPlaced: number;
    itemsSold: number;
  };
};

A stream is just a window through which Liveables are exposed.

2. Primary metric: `totalGmv`, not concurrent viewers

Most live platforms make concurrent-viewer count the lead indicator. We don't.

function primaryMetric(session: LiveSession): MetricCard {
  return {
    label: 'Live GMV',
    value: session.metrics.totalGmv,
    secondary: [
      { label: 'Items sold', value: session.metrics.itemsSold },
      { label: 'Pledges',    value: session.metrics.pledgesPlaced },
      { label: 'Viewers',    value: session.metrics.concurrentViewers },
    ],
  };
}

Leading on viewers optimizes for hype. Leading on GMV optimizes for trust. We chose the second on purpose.

3. Checkout inside the stream: 3 taps, no exit

Live commerce dies on payment friction. We force the path to be:

long-press item card → confirm modal → 1-tap purchase

Three taps. Stream never exits. Logged-in users never re-authenticate during a session.

For this to work, Shop / Crowdfunding / Event all had to share one Wallet context. That is what 'integration' actually meant in implementation: not unified UI, unified state.

4. Native app: web is the source of truth

Next phase is iOS / Android. Policy:

The web flow is the source of truth. Native ports the web; we don't fork behavior.
Web and native share the same API contracts.
Native only diverges where Apple / Google review explicitly requires it.

5. Why we didn't 'launch' today

'Web is done' means touchable, not finished. A loud launch right now would burn trust against an experience we haven't yet polished with real users.

May is for locking the foundation alongside our first event organizers and creators. June is when real operations begin and the platform starts moving for real.

In this phase, implementation logs > press releases. That's the right form of announcement for what's actually happening.

What I'd love to hear

If you've shipped commerce-adjacent live experiences: what was the seam that broke first under real load — identity, payments, moderation, or something else?

If you're still on the design side: which of these three features do you think most needs to be in the same screen as the others?

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. ko-takahashi.jp · matsuri.group · j-times.org.

I'm shipping a community-run economic platform next month. Here's what we cut, what we kept, and why.

Ko Takahashi — Mon, 04 May 2026 04:21:15 +0000

A quick build-in-public note before the launch.

This month we're shipping major updates to Matsuri Platform and The J-Times, our editorial media arm. The biggest change is live streaming integration. From June, we begin real operations.

The context: Matsuri is trying to be a community-run economic zone — a place where event organizers, local guides, cultural writers, filmmakers, and audiences earn and circulate inside a single platform, so participation translates into a livable income for as many people as possible.

Here are 5 design decisions we made along the way that I think are worth writing down before they become invisible.

1. We collapsed 4 apps into 1 platform

Early architecture had Matsuri as 4 separate apps:

Festival discovery
Editorial media (The J-Times)
Payments & ticketing
Live streaming

Independent UX, independent auth, independent billing. Faster to ship.

We collapsed them into one. The reason: a community economy needs role continuity for the same user.

User A on Tuesday: spectator
User A on Friday: event organizer
User A next week: tour guide
User A during a festival: live commerce supporter

If identity, reputation, and earnings are split across 4 apps, that continuity breaks. So we paid the integration cost up front.

2. We're avoiding 'follower count' as a primary metric

Most creator platforms make follower count the lead indicator. People who don't go viral disappear.

Our user model looks more like:

type UserRole =
  | 'organizer'
  | 'guide'
  | 'writer'
  | 'filmmaker'
  | 'vendor'
  | 'supporter';

type UserParticipation = {
  roles: UserRole[];           // a user can hold multiple roles
  contributions: Contribution[];
  reputation: ReputationScore; // tracked per role, not aggregate
  earnings: EarningStream[];   // crowdfunding + shop + live + tickets, unified
};

The primary indicator is what circulated through this user, in which role. Followers can show up later as a derived signal.

3. Live streaming is modeled as an economic event, not a broadcast

The stack underneath is comparable to YouTube Live or Twitch. The UX layer is not.

A Matsuri live event is wired so that, while the stream is running:

Shop items can be purchased mid-stream
Crowdfunding pledges to organizers can be placed
Tour bookings with the on-camera guide can be made
Viewers can publish a J-Times article off the back of the stream

The metric we care about is economic flow per stream, not concurrent viewer count.

4. We chose 'parallel cultures' over 'i18n localization'

The usual i18n model: take a Japanese UI, translate strings to English/Spanish/Portuguese.

We didn't do that. The content here is culture. A Japanese matsuri, a Brazilian festa, and a Taiwanese temple festival are not translations of each other — they're parallel.

× language=ja → language=en
○ context=jp-festival ‖ context=br-festival ‖ context=tw-festival

UI gets translated. Governance and content are local-authoritative.

5. We optimize for circulation depth, not DAU

The usual VC-backed playbook: maximize DAU/MAU first, monetize second.

We inverted it. Launch DAU targets are modest. The lead metric is how much money each participant earns and spends inside the ecosystem per month. Scale starts being interesting only after we can show the circulation is real.

Why I'm writing this now

Next month the platform is going to look like "an interesting festival app." That's the surface read. The architecture is aiming at a 3-year target: an economic zone that sustains the daily lives of hundreds of thousands of participants.

If any of this resonates with what you're building — especially if you're working on community-led economic infrastructure or DAO-adjacent platforms — I'd love to compare notes in the comments.

What's the design decision you are most likely to regret skipping when you launch?

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. More at ko-takahashi.jp. Matsuri at matsuri.group; J-Times at j-times.org.

I Got Arrogant. I Lost Everything. And Yet Here I Am, Standing at the Gate — A Reflection from 7 Years of Code

Ko Takahashi — Fri, 01 May 2026 03:12:41 +0000

Seven years of writing Rust, TypeScript, and Solidity. Same desk, same tempo, every day. This isn't a technical post. But I think the lesson behind it might be the most important thing I've learned as an engineer.

This morning, I woke up, stared at the ceiling, and thought:

"I've been at this for seven years. Why do I still feel like I'm not moving forward?"

Every day I write code. I draft ideas. I meet people. I return to my desk. There hasn't been a single day I quit. And yet, in the soft morning light, there are moments when I genuinely lose track of where I'm standing.

Maybe you have mornings like this too.

You're moving, but you don't feel it.
You're shipping, but it doesn't register.
This is a story about that kind of morning.

Chapter 1 | At Eleven, I Walked Out of School

When I was eleven, I left my public school in Shinjuku.

I couldn't articulate the reason in a child's vocabulary. The closest words I have now are these:

"This isn't where I'm supposed to be."

The lining up. The identical smiles we were trained to wear. The single answer everyone was supposed to write. My spirit never made peace with that place.

My parents were stunned. My teachers were troubled. I left anyway.

From that day on, my life carried the weight of "I decide for myself."

Chapter 2 | Ages 18–23, I Was Insufferable

From eighteen to twenty-three, I was an arrogant fool.

At eighteen, I started building organizations. They became companies. The headcount grew. The money grew. The sensation of something happening was enough to fill me up.

And then I got it completely wrong.

"How can you not even do this?"

I lost count of how many times I said it. I cut people down. I dismantled them with logic. I went cold on anyone who didn't meet my expectations. I genuinely believed I was the gifted one and everyone else just couldn't keep up.

I was leading a hundred people, and I held the heart of not a single one.

It took me a long time to see the truth.

The one who couldn't actually do anything was me.

Moving people is not the same as believing in them. Issuing orders is not the same as carrying responsibility.

The arrogant always fall. It's only a question of when.

Chapter 3 | At 23, on a Hard Floor in Thailand

At twenty-three, I was in Thailand.

I had lost almost everything. The organization. The money. The relationships. My own faith in myself. Almost all of it.

I was crashing in what they call a catch house. The floor was hard. The air conditioning didn't work. Only the pre-dawn air was strangely still.

Lying on that hard floor, eyes open, I made a vow.

No more meaningless money.

I was done living a life of half-measure profits and predictable failures.
I will build something everyone can respect — something that lasts.
I will become the real thing. No other path is permitted.

And then I made another vow.

There were people who believed in me when there was no reason to. I will repay these people with the rest of my life. That flag, I would never lower.

After that, I started going to a Buddhist temple nearby. I sat on tatami, closed my eyes, and just counted breaths. The first few days, the screaming in my head wouldn't stop. I kept sitting anyway. Every day.

It took a while for the soil to crack and the water beneath to come through.

Chapter 4 | Seven Invisible Years

That's where the seven invisible years began.

There were no fireworks. Almost no moments worth posting. The corner of a coworking space. The window seat at a library. The hotel desk at midnight. The locations changed; the work never did.

Morning meditation. A walk with English and Mandarin in my ears. Back to the desk. Code.

There were days when a single bug ate the entire day. A full twenty-four hours, not a line of progress. "What did I even do today?" I'd think, and turn off the light.

On a good day, I'd ship one feature. One. A small improvement no one would ever notice. But that was the only road forward, and I had to walk it.

One night, I told myself something I still remember:

"This is a war that has no end. And it's a war I cannot quit."

If there's no end, sprinting is pointless. If you can't quit, you can't burn out. So every day, sit at the same tempo. Walk at the same tempo. Write at the same tempo.

When asked what for?, the answer was already settled.

Someone, once, believed in me. That alone was enough.

From the outside, it must have looked like I was stuck. Inside, something was being assembled with absolute certainty. Like roots quietly spreading underground.

No dramatic breakthroughs.
Just sitting, every morning.
Just shipping, every day.

Chapter 5 | When Personal Gratitude Became Love for a Culture and the Earth

In the beginning, my motive was deeply personal.

The vow I'd made on that hard floor in Thailand, to repay a small handful of people. I thought that was all this was about.

But somewhere in those years of writing code and meditating and walking, something began to expand.

The faces of the people I owed started to blur into more faces. Behind a mentor, I could see the land that raised him. Behind the land, I could see the festivals, the shrines, the unnamed ancestors who had built it all over centuries.

One day it hit me.

The debt I want to repay is no longer the size of one human being.

The one I owe is Japan itself. The nature that gave birth to Japan. The earth that has nurtured that nature.

Then the words came.

Musubi. The ancient Japanese principle of binding what was once separated.
Matsuri DAO. Inheriting matsuri — the oldest DAO in human history, a thousand years deep — through the technology of our time. The ujiko membership system at every Shinto shrine, the kō savings circles, the flow of celebratory offerings — all of it was already a DAO archetype.

Two resolutions then crystallized.

Onko-chishin. To find the new, you must first revisit the old, deeply. Master a thousand years of Japan before designing the future.

Seishin-itto, nanigoto ka narazaran. When the spirit converges on a single point, nothing is impossible. Technology, organization, market timing — everything ultimately returns to this.

The vow on the floor in Thailand and Matsuri DAO live on the same line.

Personal gratitude became gratitude to a culture, which became gratitude to the earth.

Chapter 6 | And Yet, I'm Still Standing at the Gate

So we come back to this morning.

The morning when I wondered, "Am I actually moving forward?"

Seven years of sitting. Seven years of writing. Seven years of waiting. And still, this morning, my heart wavered.

But I got out of bed, sat down at my desk, and realized:

I am, right now, standing at the gate.

Seven years ago, the gate was far away. I couldn't even make out its shape through the haze. Now it's right in front of me. Close enough that I can reach out and feel the grain of the wood.

This past year, I've found myself at the same table as some of the world's top players. People at the frontier of the blockchain industry. Founders who are seriously trying to move culture. The inspiration I've received from them is immeasurable.

I have, at last, reached the starting line.

The seven years were preparation. The race begins now.

And this time, I will not repeat the same mistakes.

From here, I go out into the world.

A Note for Engineers

If there's one thing seven years of writing code every day taught me, it's this: the language spec is never the hardest part. The tempo is.

Not Rust's borrow checker. Not Solidity gas optimization. Not TypeScript type puzzles.

The hardest engineering problem I've ever faced was whether to open the editor again on the night a single bug ate my entire day.

Building software is the daily, gradual assembly of an abstract structure. It is closer to prayer than people admit. The line you commit today — you have no idea how it will compound tomorrow. But if you don't commit it, nothing happens.

If you've lost the feeling of moving forward, it might just be that what you're building is bigger than your own line of sight. Commit every day, and you will reach the gate. I'm telling you this after seven years. You can trust it.

The mornings when you don't feel like you're moving — those are probably the mornings you are closest to the gate.

I'll see you at the gate.

Ko Takahashi
CEO, Jon & Coo Inc. / Founder, Matsuri DAO
ko-takahashi.jp

I went to a startup pitch night on 30 hours of no sleep — what India's tech scene taught me about building

Ko Takahashi — Thu, 30 Apr 2026 07:39:23 +0000

TL;DR

Last night I attended an India–Japan co-creation pitch event hosted by Deloitte Tohmatsu in Marunouchi, Tokyo. 10+ startups, ranging from orbital debris removal to next-gen yoga mats. I went there on 30 hours of no sleep because I couldn't stop coding. I am not proud of this. This post is part lessons from the room, part open letter to fellow solo developers about the body that runs all of our code.

The Setup

I'm a solo-leaning founder shipping in Rust, TypeScript, and Solidity. I run Jon & Coo Inc., Matsuri Platform, and a few related projects. When I get into a deep build session, the world disappears. The day before this event, the world disappeared for 30 hours straight.

Don't do this. I'm writing about it here because the developer culture around sleep is, frankly, embarrassing.

What India Is Actually Bringing to the Table in 2026

Let's start with the part that should not need defending but somehow still does.

India's modern engineering ecosystem is world-class. Concrete examples that I think about when I'm planning architecture:

Aadhaar-scale identity infrastructure — biometric authentication for over a billion people, sub-second response times, designed from scratch.
UPI — a real-time, interoperable payments system processing tens of billions of transactions per month. Most "fintech" in the West has not built anything close.
Open-source contribution at scale — increasingly, the maintainers and architects of major OSS projects are based in India.
Engineering culture forged under hard constraints — cost, latency, linguistic diversity, scale.

If you are designing systems in 2026 and you are not in conversation with Indian engineering culture, you are quietly leaving capability on the table. This is not charity. This is competitive advantage.

What I Saw on the Pitch Stage

The range was the point. From the night:

Orbital debris removal — building infrastructure to clean up low Earth orbit before it becomes unusable.
Reimagined yoga mats — designing one of the most-used objects in the world from first principles, with sustainable materials.
Cross-border SaaS — built from day one to serve both Indian and Japanese markets, not bolted on as an afterthought.
Plus teams in healthtech, supply chain transparency, climate-aware materials, and dev tooling.

The thing that made this event different from a typical "international business mixer" was the technical seriousness of the founders. These are not deal-flow tourists. These are people writing code and shipping product across both ecosystems.

What This Means If You're Building Solo

A few practical takeaways for anyone building cross-border products:

1. Design for both India and Japan from day one if you can

Adding multi-region support later is technical debt. Adding multi-cultural product thinking later is architectural debt. The teams I admired most at the event had bilingual UI, currency abstraction, and locale-aware data models from their very first commit.

// Don't do this:
const formatPrice = (price: number) => `¥${price}`;

// Do this:
type Locale = 'ja-JP' | 'en-IN' | 'hi-IN';
const formatPrice = (price: number, locale: Locale, currency: 'JPY' | 'INR') =>
  new Intl.NumberFormat(locale, { style: 'currency', currency }).format(price);

It looks trivial. It is not trivial. The first version locks you into a single market mental model.

2. Talk to Indian engineers about constraints you've never had to think about

Cost-per-API-call thinking. Mobile-first under intermittent connectivity. Multi-script rendering. Edge cases in scaling that don't exist when your user base is in San Francisco.

Even if your product never ships to India, this conversation makes you a better engineer.

3. Respect the long arc

The cultural and intellectual exchange between India and Japan is not new. It is at least 30,000 years old, traceable through deep haplogroup connections, the migration of the Saka, and Buddhism arriving in Japan as Shaka. When two civilizations have been in dialogue for that long, "international partnership" stops being a slogan and starts being a continuation.

This is not just romantic. It actually changes how you negotiate, design, and build.

The Embarrassing Part: Solo Developer Health

OK now the part I owe you.

I went to this event after coding for 30 hours straight. I am very lucky that the talks were interesting enough to keep me alert. They could just as easily not have been, and I would have been the guy nodding off in the second row of a high-stakes networking event.

Here is the rule I am committing to publicly so it costs me something to break:

Laptop closes at 22:00 the night before any high-stakes event. No exceptions.

And here is the broader operating doctrine I'm trying to live by as a solo dev:

Practice	Why it matters
Yoga (daily, even 15 min)	Resets posture, breath, and nervous system. Reverses the damage of a screen-bound day.
Meditation (daily, 15-20 min)	Cache-clear for the mind. Improves the quality of subsequent decisions dramatically.
Sleep (7+ hours, non-negotiable)	The body's nightly garbage collector. Skip it and your decision-making LRU cache fills with stale entries.
Movement (walk, stretch, lift)	Circulation. Solo coding is a sedentary occupation by default — don't let it stay that way.
Intentional rest (scheduled idleness)	Not "scrolling Twitter." Actual nothing. Counterintuitive, essential.

For a solo dev, these are not lifestyle accessories. They are part of the system architecture. Your body is not a bug you patch at the end of the sprint. It's the runtime.

A Quick Note on Yoga and Meditation, Specifically

I want to address something. In Western dev culture, yoga and meditation often get framed as "wellness lifestyle stuff." That framing makes them easy to dismiss when a deadline looms.

In Japan, in India, and across much of Asia, these practices are not lifestyle. They are foundational technologies for the body and mind, refined over thousands of years. I take them seriously the same way I take version control seriously: because the system doesn't work without them.

If you've been treating them as optional, I'd gently invite you to give them a real two-week trial. Same energy you'd give a new framework you're evaluating.

Closing

The vow I walked away with from Marunouchi:

Learn together. Build together. Hold each other up. Be partners in healing what is broken in the world.

That is the cross-border collaboration brief I want to live by. And the only way I get to participate in it for the next 30 years is by getting better at sleep tonight.

If you're a solo dev, or you're building cross-border between India and Japan (or anywhere, really), drop a comment. What's one practice that has actually stuck for you? I'm collecting data points.

Ko Takahashi — Entrepreneur, Philosopher, Engineer
CEO of Jon & Coo Inc. | Lead Architect of Matsuri Platform | Editor in Chief of The J-Times
Tokyo. ko-takahashi.jp

What 10,000 Web3 People From 50 Countries Taught Me About Japan's Real Role — TEAMZ Summit 2026

Ko Takahashi — Mon, 27 Apr 2026 22:37:42 +0000

April 7, Shirokanedai, Tokyo

Tour buses kept pulling into Happo-en, a 400-year-old garden in central Tokyo. Justin Sun had already arrived. Charles Hoskinson was joining remotely, but his face on the giant screen was already the center of the venue. Japan's Minister of Finance and Financial Services, Satsuki Katayama, would deliver her keynote in less than an hour.

10,000 attendees from 50 countries. 130+ speakers. Theme: "Tradition Meets Tomorrow."

This was TEAMZ Summit 2026 — Asia's largest Web3 / AI conference. As the lead architect of Matsuri Platform, there was no reason for me not to be there.

And at the edge of the crowd, I felt a quiet sense of dissonance.

Geisha, sumo, karate — and not a single ironic gaze

Geisha performed traditional dance. Sumo wrestlers appeared on stage. A karate demonstration filled the main hall. At any normal tech conference, this would read as "a bit of local color for the foreigners."

But not a single overseas attendee — VC, founder, engineer — looked at it that way. They photographed it intently. They discussed it in their own languages. And during the next sessions, multiple speakers said out loud: "I want to build something that connects to Japanese culture."

That was the dissonance:

Web3 leaders from outside Japan see Japanese culture as an asset, not a decoration. And Japan's own Web3 projects haven't quite noticed.

Three hallway conversations, one shared problem

Between sessions, I deliberately walked the corridors. I wanted to talk to booth operators and side-event founders more than to keynote speakers.

Person 1 — CEO of an L2 protocol based in Singapore: "We want to launch in Japan but don't know where to start. We're terrified of getting the cultural messaging wrong."

Person 2 — A family office investor from the UAE: "We want to NFT-ize Japanese traditional crafts, but there's no direct path to the artisans themselves."

Person 3 — A young builder from Brazil: "I want to run my city's samba carnival on the same protocol that runs Kyoto's matsuri. Could you share the tech stack?"

Three people. Three countries. Three industries. All stuck in the same place: there's no entry point to participate in Japanese culture.

In that moment, two things hit me:

The platform we'd been building for two years had been designed precisely to be that entry point. GCF membership, KYC, a Shop in five languages, Crowdfunding tied to cultural context, Live that connects audiences from anywhere in the world to the same instant. It almost looked as if Matsuri had been built for exactly these three people.
I hadn't fully realized this myself until that hallway conversation.

A quiet pond, and the answer that arrived

Later that afternoon, I left the crowd and sat by a small pond inside Happo-en. Koi moved slowly under the surface. Wind shook the branches. The roar of the venue suddenly felt distant.

In that quiet, a sentence formed clearly in my head:

Japan's role in Web3 isn't crypto trading or new tokenomics inventions. It's renting out, to the rest of the world, the 1,300 years of accumulated technique for keeping a community alive.

Web3 globally is unmatched at mechanism design and capital formation. But it has almost no track record at designing communities that survive a hundred years. Japan, on the other hand, has that experience in abundance — but lacks the distribution format that Web3 provides.

The two are complementary. And Matsuri can be one of the concrete implementations that makes that complementarity functional.

On the train back, one line in my notes

That evening, on the Yamanote line back from Shirokanedai to Shinjuku, I opened my notes app and typed exactly one sentence:

"Japan can become an exporter in Web3. But what we'll export isn't tokens — it's **community technique."

Two years ago, the night I wrote the first commit for Matsuri, I'd written something similar. Back then it was an unproven hunch. Tonight, it isn't.

Every face I'd made eye contact with that day — across 50 countries — had reinforced the hypothesis a little more.

A question for you

If you build things in Japan, ask yourself: Among the things you do unconsciously, the community techniques you take for granted — is there one that someone abroad is struggling to buy?

There probably is.

If you find it, please tell me. Matsuri might be one of the export lines for it.

Matsuri Platform: https://matsuri.group
Matsuri DAO: https://www.matsuri-dao.com
Site: https://www.ko-takahashi.jp

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform. Entrepreneur, Philosopher, Engineer. Based in Shinjuku, Tokyo.

Why I Built Shop, Crowdfunding, and Live Into One Platform — A Festival Economy on Web3

Ko Takahashi — Mon, 27 Apr 2026 22:35:51 +0000

A line I added to a memo two years ago

I still remember the night I wrote the first commit, two years ago. In the corner of a memo titled "Digitizing Japanese festivals," I scribbled one extra line: "But never let it become just a booking site."

That line finally became code.

In the past few weeks, Matsuri has shipped Shop (a marketplace) and Crowdfunding, and Live (real-time streaming) launches in days. The moment those three features stood next to each other, I finally saw what we'd actually been building.

Matsuri is a festival economy — not a booking platform.

I built Shop because vendors couldn't sell online

A festival isn't just for tourists. The carver of mikoshi, the family hand-painting lanterns, the food vendor serving the same recipe for 30 years — a festival runs on thousands of tiny economies stitched together.

None of them can sell online. They don't have engineers. They can't configure Stripe. They can't manage SKUs.

So I built one checkout that unifies Stripe Connect, Solana settlement, and MTC (Matsuri Coin) balance. Any KYC-verified GCF member can list. Fee: 5% (1% to the inviter who introduced the buyer).

# accounts/services/shop_checkout.py
@transaction.atomic
def checkout_with_sku(cart, payment_method):
    inventory = (Inventory.objects
        .select_for_update()  # race-safe
        .get(sku_id=cart.sku_id))
    if inventory.available < cart.quantity:
        raise OutOfStockError
    # 5% fee split: 4% platform + 1% Lv1 referrer
    FeeLedger.record_split(order, fee_pct=Decimal('5'))
    return process_payment(payment_method, order.total)

SKU allocation is race-safe with select_for_update(), fee split is logged in 3 rows in the FeeLedger.

I built Crowdfunding to route capital to the festivals worth saving

Every year, festivals disappear because of depopulation. Lion-dance lineages break. Floats can't be repaired. Sacred objects rot.

Three principles locked the design:

6% fee (4% platform + 2% Lv1 referral commission)
All-or-Nothing — if a campaign misses its goal, Celery beat auto-refunds every backer
Lv2+ commission is zero — refused to build a multi-tier MLM

Rewards are NFTs, MTC, live-stream access, on-site experiences. "Backing" and "participating" become the same verb.

I built Live because synchronicity is the soul of a festival

The essence of a festival is synchronicity. The same instant, the same place, the same shared something. That's why these things have lasted 1,300 years.

So Live isn't a streaming feature. On a low-latency stack (LiveKit + Hetzner), one screen runs:

Real-time tipping (Stripe Client Secret / MTC / Solana 7-step verification)
Viewer count + 60s heartbeat (Celery 30s beat for expiration)
3-2-1 countdown (1 Hz APNs push)
Live-only coupons (claim → apply → authoritative recompute → redeem)
In-stream NFT drops (with recording markers)
Paywalled archives (5-mode access)
5-language chat (BCP-47 → internal lang normalization)

// Canonical 1-type cue event for the WS protocol
socket.on('cue', (msg) => {
  switch (msg.data.phase) {
    case 'preroll':   showCountdown(msg.fire_at); break;
    case 'execute':   triggerCueAction(msg.kind);  break;
    case 'completed': markExecuted(msg.cue_id);    break;
    case 'failed':    markSkipped(msg.cue_id);     break;
  }
});

247 live tests pass. Django check: 0 issues. Frontend: TypeScript strict, zero warnings. Boring numbers, but that's the proof of intent.

Why all three only make sense together

Decomposed structurally, a festival is three things:

Festival element	Matsuri feature
Exchange of goods (stalls, souvenirs, crafts)	Shop
Pooling of resources (festival dues, donations, repairs)	Crowdfunding
Sharing of time (mikoshi processions, lion dances, offerings)	Live

Festivals 1,300 years ago and festivals today both run on these three.

If you only need one of them, use Shopify, Kickstarter, or Twitch. The reason Matsuri must exist on Web3 is the cultural context that ties the three together.

We finally made it here

Two years ago I started writing this alone. Today: backend 450 tests, frontend 0 errors, 9 migrations, 5 languages, three clients (iOS / Android / Web), 20+ internal docs.

The real festival hasn't started yet. The night Live launches, when someone in Kyoto runs a small local matsuri and people in Tokyo, New York, and Rio watch and tip the same instant — that's the night Matsuri actually boots up.

If you've been looking for a way to use Web3 not for speculation but for keeping culture alive, come take a look.

Matsuri Platform: https://matsuri.group
Matsuri DAO: https://www.matsuri-dao.com

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform. Entrepreneur, Philosopher, Engineer. Based in Shinjuku, Tokyo. Building at the intersection of Japanese culture and Web3. https://www.ko-takahashi.jp

The Kami in the Code: Japan's Technology, Past, Present, and the Spirituality That Will Shape Its Future

Ko Takahashi — Fri, 10 Apr 2026 08:08:03 +0000

The "Lost Three Decades" Story Is Half Wrong

In the 1980s, Japan was the center of the technological world.

Sony's Walkman didn't just play music; it invented the very act of carrying music with you. Toyota's Just-in-Time rewrote the philosophy of manufacturing. Nintendo's Famicom released "play" into the living room. Ezra Vogel wrote Japan as Number One in 1979. Back then, the world was trying to learn from Japan.

Then the story goes: the bubble burst, the iPhone arrived, Big Tech rose, China rose, and Japan sank into its "Lost Three Decades."

This story is only half true.

By market cap, yes, Japanese tech companies were left far behind by the American and Chinese giants. Japan's share of global semiconductors fell from over 50% in 1988 to below 10%. No cloud, no SaaS, no mobile OS built in Japan became a global standard. This is real. We should not look away.

But during that same three decades, Japan was quietly playing a different game. Not the game of short-term spectacle, but the game of long-term layering—the accumulation of monozukuri (craft-making) and philosophy. And now, in 2026, the dividends of that game are finally showing up on the balance sheet.

A Realistic Map: What Is Japanese Technology Actually Doing Right Now?

Let's look coldly at the numbers.

In semiconductor manufacturing equipment, Japan still holds more than 30% of the global market when you combine Tokyo Electron, Disco, Advantest, and SCREEN. The high-purity photoresists used in EUV lithography are nearly monopolized by JSR, TOK, and Shin-Etsu. Silicon wafer materials from Shin-Etsu and SUMCO account for over half the world's supply. In other words, in the layer of tools and materials required to make cutting-edge chips, Japan has not disappeared. It has quietly buried itself into the indispensable layer.

Rapidus launched its pilot line in 2025 and is aiming for 2nm mass production by 2027. Preferred Networks is carving out an alternative low-power path with its MN-Core architecture, refusing to surrender to the NVIDIA monoculture. Sakana AI has offered the world a clear counter-thesis to scale-at-all-costs by using evolutionary algorithms to build small, clever models.

In robotics, FANUC, Yaskawa, and Denso Robotics together supply roughly half of the world's industrial robots. In humanoids, there's a lineage running from Toyota's Punyo through Kawasaki's Kaleido and Sony's aibo. In cultural exports, anime, games, food, and inbound tourism are adding quietly but steadily to GDP. Inbound visitors exceeded a record-breaking 36 million in 2024 and continued climbing in 2025. Japanese anime has become a permanent resident of Netflix's global top 10. Japanese indie games on Steam now have a presence unthinkable a decade ago.

These facts look scattered. But if you draw a single line through them, what do you see?

What Japan Spent Thirty Years Accumulating Was Depth

American tech chose speed. Move fast and break things.
Chinese tech chose scale. The sheer implementation power to pull in a billion users in a few years.
Both are great strategies and both produced great wealth.

Japan, whether by accident or by instinct, was accumulating something different. Depth.

The precision of a single screw. The atomic arrangement on a wafer surface. The drawing of a single frame of anime. The temperature of the rice in one piece of sushi. The height of the tatami border in a tea room. The joint of a wooden pillar in a shrine. None of these can be justified by short-term rationality. They have been polished by an investment of time that market logic alone cannot explain.

And this obsession with depth does not come from the surface of Japanese culture. It comes from a deeper layer—one we can only call spirituality.

Why does a Japanese craftsman finish the hidden back of his work with the same care as the front? Because he believes kami (god/spirit) dwells there. This is not a metaphor. Yaoyorozu no kami (the eight million gods), tsukumogami (spirits of well-used tools), musubi (the principle of binding)—in the old Japanese worldview, spirit dwells in objects and in nature, and the act of a human hand "binding" them gives birth to new life. To make a thing is to pray.

In the age of AI and Web3, this spirituality is no longer an "old Japan story." It has become the missing component that the frontier of technology needs most.

The Wall Technology Hit, and the Key Japan Holds

The questions that keep engineers in Silicon Valley up at night are, almost without exception, philosophical questions.

How do you implement ethics into an AI that has scaled beyond comprehension? What is a product that does not exploit the user's attention? Who should own data? When you run a community as a DAO, how do you design for harmony rather than conflict? After humans hand their work to AI, what remains for us?

You cannot answer these questions by adding more GPUs. You cannot answer them with a bigger funding round. These are not engineering questions. They are questions about what a human is and what the world is. And Japan has been layering answers to these questions for more than 1,300 years.

Matsuri—Japanese festivals—are a 1,300-year-old prototype of the DAO. No central authority decides who carries the portable shrine. The decision floats between local consensus and the invisible will of the kami. No one owns it. No one becomes the winner. And yet, every year, it runs. This is a prototypal implementation of exactly the problem Web3 communities are currently trying to solve.

Shinto refuses to separate nature from the artificial. A shrine is ritually rebuilt every twenty years (shikinen sengu). The building is not the essence—the continuity of "the skill and heart to keep rebuilding" is. This is strikingly close to how an open-source repository preserves its essence through continuous refactoring.

Wabi-sabi—the aesthetic of finding beauty in imperfection—already contains an answer to the modern question of how to live alongside AI that hallucinates.

A Zen koan is training for touching truth through a logical leap. This is adjacent to the exact problem LLM researchers are groping at today: how to cultivate emergence beyond pattern recognition.

So: the future of Japanese technology is not about "catching up with the West." That game is over. What Japan must do instead is take 1,300 years of spiritual accumulation, translate it into a language the world can read, and re-implement it in code, in institutions, and in products.

The Case for Optimism Is Structural, Not Emotional

Let me make the structural case for optimism, without sentiment.

First, whoever owns the layer of tools and materials eventually reclaims leverage. Japan may have lost the application layer. But in the layer beneath it—chips, materials, precision machines, robots—Japan remains immovable. As AI descends into the physical world (robotics, autonomous driving, manufacturing), the importance of this layer only grows.

Second, population decline is not a bug. It is a specification. Many lament Japan's aging society. But flip the frame: Japan, earlier than any other country, must answer the question "how do you preserve quality in a society whose labor force keeps shrinking?" This is the strongest possible incentive to automate, to build robots, to deploy AI. A country that faces the future first becomes a country that exports solutions.

Third, cultural capital compounds. Anime, games, food, tourism, craft, shrines and temples, artisan skill—these are not content to be consumed in a quarter. They are assets that accumulate brand over a hundred years. In an age where generative AI can infinitely duplicate anything, the paradoxical value of the non-duplicable—place, history, texture—rises.

Fourth, and most fundamentally, the young generation of Japanese creators and engineers now holds weapons that their grandparents' generation never had. English. Open-source culture. Direct connection to overseas communities. Web3. Generative AI. And most importantly, a self-esteem that is no longer embarrassed to be "the Japanese self." This combination has never existed in any prior generation. I am one of this generation, and I feel its texture every week.

Passionate, But Logical

Do not misread me. I am not saying Japan can win on spirit alone.

Semiconductor lithography obeys the laws of physics. The attention mechanism of a transformer obeys linear algebra. A smart contract obeys the EVM. Bring mysticism into any of these and you simply lose.

What I am saying is this: the skeleton of technology is universal, but the direction vector—what it is used for, whom it is used for, how deeply—comes from culture and spirituality. And technology without a direction vector eventually either runs amok or becomes a commodity copy.

America had "freedom" as its direction vector. That's how it ruled. China has "nation and development" as its direction vector. That's how it scaled. Japan, for a long time, forgot what its own direction vector was. Copies of the West. Cheap manufacturing. Efficiency. All borrowed clothes.

Now we are finally remembering.

"Wa wo motte toutoshi to nasu"—"With harmony is nobility made." 1,400 years ago, Prince Shotoku wrote this as the first article of Japan's seventeen-article constitution. Not conflict but integration. Not conquest but harmony. Not ownership but inheritance. This is not the conformist groupthink the stereotype implies. It is a philosophy that, while respecting difference, places value on re-binding what has been separated.

This philosophy is pointing in the same direction that Web3, AI alignment, climate response, and democratic re-design are all currently searching for answers. That is not a coincidence. Humanity's questions have come full circle, and they are back to: how do we bring the different into harmony?

Our Role: Code as Prayer

So when I write code in the morning, I want to strike the keyboard the way one strikes a bell at a shrine.

Coldly as a business. Logically as an engineer. And yet, somewhere in the back of my mind, believing that one function might lighten one moment of one person's life. Hoping that one DAO might survive for hundreds of years like a festival. Imagining that one protocol might, like the joint of a shrine's wooden pillar, quietly outlast time.

The future of Japanese technology is not to beat Big Tech. It is to answer the questions Big Tech cannot answer—answer them from our culture and our spirituality—and then translate those answers into code the world can read, products the world can touch, and stories the world can feel.

Is that too grand a dream?

I don't think so. Because it has already begun. Matsuri Platform. Sakana AI. Rapidus. Preferred Networks. Countless indie games. The quiet components makers who silently keep the world running. The young researchers who have finally started presenting at international conferences. The dots are already being placed. What's missing is only the line that connects them, and the language that turns that line into a story.

I want to be on the side that writes that language. And I want you to stand on the same side.

Let us dwell kami in our code. Let us fold prayer into our products. Let us choose depth over scale, inheritance over speed, musubi (binding) over ownership.

Japanese technology is not finished. It has only just remembered who it is.

Ko Takahashi / 高橋高
Entrepreneur, Philosopher, Engineer
CEO, Jon & Coo Inc. | Lead Architect, Matsuri Platform | Editor in Chief, The J-Times
ko-takahashi.jp

What I Learned About DAO Governance From a 1,300-Year-Old Japanese Festival System (TEAMZ Summit 2026)

Ko Takahashi — Tue, 07 Apr 2026 16:37:27 +0000

I just came back from TEAMZ Web3/AI Summit 2026 in Tokyo — held at Happo-en, a 400-year-old Japanese garden. 10,000 attendees, 130+ speakers, 50 countries represented.

But the most important thing I learned didn't come from a session. It came from watching a sumo performance next to a blockchain demo.

The Thesis: Festivals Are the Original DAOs

I'm building Matsuri Platform, which digitizes Japanese festival culture using Web3 technology.

Japanese festivals (matsuri) have been running as decentralized autonomous systems for 1,300+ years:

No central authority — community members self-organize
Role rotation — leadership changes annually
Resource allocation — communal funding without centralized treasury management
Reputation-based trust — participation history determines responsibilities

Sound familiar? That's a DAO.

Code: Matsuri-Inspired DAO Governance

Here's a conceptual model I've been prototyping in Rust (Substrate framework):

#[derive(Clone, Debug, Encode, Decode)]
pub struct MatsuriRole {
    pub role_type: RoleType,
    pub assigned_to: AccountId,
    pub term_blocks: BlockNumber,
    pub responsibilities: Vec<Responsibility>,
    pub reputation_weight: u32,
}

pub enum RoleType {
    Ujiko,     // Community member
    Nushi,     // Leader — rotates annually
    Kannushi,  // Validator/Oracle role
    Miyashi,   // Governance administrator
}

impl MatsuriDAO {
    /// Annual rotation based on reputation-weighted selection
    pub fn rotate_leadership(&mut self) -> Result<(), GovernanceError> {
        let candidates = self.members
            .iter()
            .filter(|m| m.reputation >= MINIMUM_REPUTATION)
            .filter(|m| !self.recent_leaders.contains(&m.account))
            .collect::<Vec<_>>();

        let next = self.weighted_random_selection(&candidates)?;
        self.assign_role(next.account, RoleType::Nushi)?;
        self.recent_leaders.push(next.account);
        Ok(())
    }

    /// Reputation accrues through participation, not token holdings
    pub fn record_participation(
        &mut self,
        member: &AccountId,
        event: &EventId,
    ) -> Result<(), GovernanceError> {
        let contribution = self.evaluate_contribution(member, event)?;
        self.update_reputation(member, contribution.weight)?;
        Ok(())
    }
}

Key design decisions inspired by matsuri governance:

Reputation over tokens — In festivals, your standing comes from showing up and contributing, not from how much money you have
Mandatory rotation — No permanent leaders. This prevents the "whale governance" problem in most DAOs
Seasonal cycles — Governance operates on natural cycles, not continuous voting fatigue

What I Saw at TEAMZ: AI x Web3 Is Real Now

Beyond the cultural inspiration, the summit showed me that the AI x Web3 convergence isn't theoretical anymore:

// RWA Valuation Pipeline (conceptual)
interface RWAAsset {
  assetType: 'real_estate' | 'art' | 'ip' | 'cultural_heritage';
  onChainId: string;
  valuation: {
    aiModel: string;
    baseValue: bigint;
    confidence: number; // 0-1
    lastUpdated: number;
  };
}

async function getAIValuation(asset: RWAAsset): Promise<Valuation> {
  const marketData = await oracle.fetchMarketData(asset.assetType);
  const comparables = await oracle.fetchComparables(asset);
  return aiModel.evaluate({ marketData, comparables });
}

Finance Minister Katayama's session made it clear: Japan is building world-leading stablecoin regulation. For builders, that means regulatory clarity leads to faster shipping.

3 Takeaways for Web3 Builders

Look outside tech for governance inspiration. 1,300 years of festival governance > 5 years of DAO experimentation.
Japan is becoming the regulatory gold standard. Build for Japanese compliance and you'll likely be ahead globally.
AI + Web3 is the default stack now. If you're building Web3 without AI integration, you're building yesterday's product.

What's Next

I'm open-sourcing parts of the Matsuri DAO governance model. If you're interested in culturally-inspired DAO design, follow me or check out ko-takahashi.jp.

Have you seen interesting governance patterns from non-tech domains? I'd love to hear about them in the comments.

Ko Takahashi — Entrepreneur, Philosopher, Engineer
CEO of Jon & Coo Inc. | Lead Architect of Matsuri Platform

World in Chaos, Japan at a Crossroads: Why Wa (Harmony) Is the Governance Model the World Needs

Ko Takahashi — Sun, 29 Mar 2026 00:02:44 +0000

The World in 2026: A New Warring States Era

The World Economic Forum's Global Risks Report 2026 ranks geoeconomic confrontation, misinformation, and societal polarization as the top short-term risks facing humanity. PwC Japan identifies the limits of Pax Americana as the defining geopolitical trend. Some analysts compare the current international order to Japan's own Sengoku period -- a warring states era where might made right.

I'm Ko Takahashi -- entrepreneur, philosopher, and engineer. As CEO of Jon & Coo Inc. and Lead Architect of the Matsuri Platform, I work at the intersection of Japanese culture and technology. In this chaos, I keep returning to a principle that has guided Japan for over 1,300 years: Wa -- the spirit of harmony.

The Architecture of Chaos vs. The Architecture of Harmony

Three Forces Driving Global Division

1. Weaponization of Economy -- Tariffs, sanctions, supply chain fragmentation. Economic activity has become a geopolitical weapon.

2. Weaponization of Information -- Deepfakes, algorithmic echo chambers. People see only the reality they want to see.

3. Politicization of Identity -- Ethnic, religious, ideological divisions deepen the "us vs. them" binary worldwide.

What these share is a Force Protocol -- win or lose, dominate or submit.

Wa Is the Opposite

In 604 CE, Prince Shotoku's Seventeen-Article Constitution began with: "Harmony is to be valued." This wasn't a moral platitude -- it was a governance principle.

The essence of Wa is a system where different things coexist while remaining different. In software architecture terms, this is loose coupling -- each component maintains independence while cooperating as a whole.

Japan at a Crossroads: A Fighting Nation or a Harmonizing Nation?

Japan faces a historic choice. As The Diplomat analyzes, the country must decide whether to continue its 80-year pacifist path or become a "normal country" with expanded military presence.

My view is clear: Japan's greatest value to the world is not military power -- it's the Wa governance model.

Matsuri: Wa in Action

While designing the Matsuri Platform, I realized something: Japanese festivals are decentralized governance systems that have functioned for 1,300+ years.

No central authority. Each neighborhood carries its own mikoshi, pulls its own float. Yet the whole event harmonizes beautifully. Why? Because of kata (shared protocols).

Here's what this looks like in code:

// The Wa Governance Model -- Loosely Coupled Autonomous Systems
trait WaProtocol {
    /// Each participant makes independent decisions
    fn make_local_decision(&self) -> Decision;

    /// But harmonizes with the community via shared protocol
    fn harmonize_with(&self, community: &Community) -> HarmonizedAction;

    /// Conflicts resolved through dialogue, not force
    fn resolve_conflict(&self, other: &dyn WaProtocol) -> Resolution {
        Resolution::ConsensusThrough(Dialogue::new())
    }
}

/// The Force Model (for comparison)
trait ForceProtocol {
    fn dominate(&self, other: &dyn ForceProtocol) -> Winner;
    // Only winners and losers exist
}

WaProtocol preserves autonomy while enabling harmony. ForceProtocol produces only winners and losers. The current world order runs on the latter. But what has endured for 1,300 years is the former.

Implementing Wa in Daily Life

1. Design for Listening

In engineering, systems must listen before they respond. The same applies to human relationships.

interface WaDialogue {
  listen(other: Perspective): Understanding;
  respond(understanding: Understanding): HarmoniousResponse;
  agree_to_disagree(topic: Topic): MutualRespect;
}

2. Architect for Difference

Wa is not about becoming the same. As Confucius taught: "The noble person harmonizes but does not conform." In Matsuri DAO, I design governance where participants don't need to share the same opinion -- they need structures that let different perspectives coexist.

3. Start with Small Wa

World peace is distant. But listening to someone fully today, not attacking reflexively on social media, asking "why do you think that?" instead of dismissing -- these are small acts of Wa you can practice right now.

Each person creates a small circle of Wa. That circle overlaps with others. Like the ripples in a zen garden's raked sand, one stone creates waves that spread outward.

Conclusion: Culture Outlasts Technology

The world in 2026 is chaotic. But chaos births new order. Japan has 1,300+ years of implementing and operating Wa as a harmony protocol.

Choosing harmony over conflict is not weakness. It's the most robust governance model -- one that passed a 1,300-year stress test.

Culture outlasts technology. And Wa outlasts force.

What small act of Wa will you practice today?

Ko Takahashi -- Entrepreneur, Philosopher, Engineer
CEO of Jon & Coo Inc. | Lead Architect of Matsuri Platform
Shinjuku, Tokyo | ko-takahashi.jp

What an 87-Year-Old Festival Elder Taught Me About AI Agent Governance — Implemented in Rust

Ko Takahashi — Sat, 28 Mar 2026 03:56:55 +0000

How I Met an 87-Year-Old Festival Elder

In the fall of 2024, I met an 87-year-old festival elder in a small mountain village near Kyoto. He oversees an autumn festival with a 1,300-year history — over 30 neighborhood associations participate, involving thousands of people in a massive decentralized operation. No central server. No Slack channels.

"A festival doesn't run because someone gives orders. It works because everyone knows their role."

That one sentence fundamentally changed how I design AI agent systems.

The Governance Crisis of Modern AI Agents

In 2026, AI agents are everywhere. But serious problems are emerging.

Problem 1: Runaway Autonomy

# A common AI agent failure pattern
agent.execute("optimize costs")
# → Agent shuts down all servers
# → "Costs optimized (reduced to zero)"

Problem 2: No Escalation

Most AI agent frameworks only have a simple fallback: "ask a human when confused." The festival elder taught me something far more nuanced — graduated escalation.

Problem 3: Lost Context

Agents forget the "why" behind past decisions. Festivals preserve centuries of "why we do things this way" through oral tradition and customs.

Principle 1: Bounded Autonomy

Each neighborhood association has full autonomy within their zone — but with clear boundaries. Here's how I implement this in Rust:

use std::collections::HashMap;
use chrono::{DateTime, Utc};

/// Applying festival "roles and responsibility boundaries" to AI agents
#[derive(Debug, Clone)]
pub struct BoundedAutonomy {
    pub resource_bounds: ResourceBounds,
    pub temporal_bounds: TemporalBounds,
    pub permission_scope: PermissionScope,
}

#[derive(Debug, Clone)]
pub struct ResourceBounds {
    pub cost_ceiling: f64,
    pub current_cost: f64,
    pub max_api_calls_per_minute: u32,
    pub max_memory_mb: u64,
    pub writable_stores: Vec<String>,
    pub max_records_per_action: usize,
}

#[derive(Debug, Clone)]
pub struct TemporalBounds {
    pub max_task_duration: std::time::Duration,
    pub session_expiry: DateTime<Utc>,
    pub cooldown_period: std::time::Duration,
}

#[derive(Debug, Clone)]
pub struct PermissionScope {
    pub readable: Vec<String>,
    pub writable: Vec<String>,
    pub executable: Vec<String>,
    pub denied: Vec<String>,
}

impl BoundedAutonomy {
    pub fn validate_action(&self, action: &AgentAction) -> Result<(), GovernanceError> {
        if self.resource_bounds.current_cost + action.estimated_cost 
            > self.resource_bounds.cost_ceiling {
            return Err(GovernanceError::CostCeilingExceeded {
                current: self.resource_bounds.current_cost,
                requested: action.estimated_cost,
                ceiling: self.resource_bounds.cost_ceiling,
            });
        }
        if Utc::now() > self.temporal_bounds.session_expiry {
            return Err(GovernanceError::SessionExpired);
        }
        if self.permission_scope.denied.iter()
            .any(|d| action.target_resource.starts_with(d)) {
            return Err(GovernanceError::PermissionDenied {
                resource: action.target_resource.clone(),
                reason: "Resource is in denied list".to_string(),
            });
        }
        Ok(())
    }
}

#[derive(Debug, Clone)]
pub struct AgentAction {
    pub name: String,
    pub target_resource: String,
    pub estimated_cost: f64,
    pub risk_level: RiskLevel,
}

#[derive(Debug, Clone)]
pub enum RiskLevel { Low, Medium, High, Critical }

#[derive(Debug)]
pub enum GovernanceError {
    CostCeilingExceeded { current: f64, requested: f64, ceiling: f64 },
    SessionExpired,
    PermissionDenied { resource: String, reason: String },
    EscalationRequired { level: String, context: String },
}

Principle 2: Graduated Escalation

When problems arise at a festival, you don't immediately report to the elder. First the squad leader, then the association head, then the committee.

#[derive(Debug, Clone, PartialEq, PartialOrd)]
pub enum EscalationLevel {
    SelfResolve,
    PeerConsult,
    OrchestratorReport,
    HumanEscalation,
    EmergencyHalt,
}

pub struct EscalationEngine {
    pub thresholds: HashMap<String, f64>,
    pub history: Vec<EscalationEvent>,
}

impl EscalationEngine {
    pub fn calculate_level(&self, ctx: &ActionContext) -> EscalationLevel {
        let risk = self.calculate_risk(ctx);
        match risk {
            s if s < 0.2 => EscalationLevel::SelfResolve,
            s if s < 0.5 => EscalationLevel::PeerConsult,
            s if s < 0.75 => EscalationLevel::OrchestratorReport,
            s if s < 0.95 => EscalationLevel::HumanEscalation,
            _ => EscalationLevel::EmergencyHalt,
        }
    }

    fn calculate_risk(&self, ctx: &ActionContext) -> f64 {
        let base = match ctx.action.risk_level {
            RiskLevel::Low => 0.1,
            RiskLevel::Medium => 0.3,
            RiskLevel::High => 0.6,
            RiskLevel::Critical => 0.9,
        };
        let fail_rate = self.history.iter()
            .filter(|e| e.context.contains(&ctx.action.name))
            .filter(|e| e.resolution.is_none())
            .count() as f64 / self.history.len().max(1) as f64;
        (base + fail_rate * 0.3).min(1.0)
    }
}

Principle 3: Contextual Memory

The most remarkable aspect of festivals is preserving centuries of institutional knowledge.

#[derive(Debug, Clone)]
pub struct ContextualMemory {
    pub episodes: Vec<Episode>,
    pub rules: Vec<Rule>,
    pub max_capacity: usize,
}

impl ContextualMemory {
    pub fn recall(&self, ctx: &HashMap<String, String>, limit: usize) -> Vec<&Episode> {
        let mut scored: Vec<_> = self.episodes.iter()
            .map(|ep| (self.relevance(ep, ctx), ep)).collect();
        scored.sort_by(|a, b| b.0.partial_cmp(&a.0)
            .unwrap_or(std::cmp::Ordering::Equal));
        scored.into_iter().take(limit).map(|(_, ep)| ep).collect()
    }

    fn relevance(&self, ep: &Episode, ctx: &HashMap<String, String>) -> f64 {
        let mut score = 0.0;
        for (k, v) in ctx {
            if ep.context.get(k).map_or(false, |ev| ev == v) { 
                score += 1.0; 
            }
        }
        let age = (Utc::now() - ep.timestamp).num_days() as f64;
        score * (0.3 + 0.7 * (-age / 365.0).exp())
    }
}

Putting It All Together: MatsuriGovernanceFramework

pub struct MatsuriGovernanceFramework {
    pub autonomy: BoundedAutonomy,
    pub escalation: EscalationEngine,
    pub memory: ContextualMemory,
}

impl MatsuriGovernanceFramework {
    pub fn govern_action(&mut self, action: AgentAction, ctx: ActionContext)
        -> Result<ActionResult, GovernanceError>
    {
        // Step 1: Boundary check
        self.autonomy.validate_action(&action)?;
        // Step 2: Recall past experiences
        let episodes = self.memory.recall(&ctx.environment, 5);
        let failures: Vec<_> = episodes.iter()
            .filter(|ep| matches!(ep.outcome, Outcome::Failure { .. }))
            .collect();
        // Step 3: Determine escalation level
        let mut level = self.escalation.calculate_level(&ctx);
        if !failures.is_empty() {
            level = match level {
                EscalationLevel::SelfResolve => EscalationLevel::PeerConsult,
                EscalationLevel::PeerConsult => EscalationLevel::OrchestratorReport,
                other => other,
            };
        }
        // Step 4: Act based on escalation level
        match level {
            EscalationLevel::SelfResolve | EscalationLevel::PeerConsult =>
                Ok(ActionResult::Proceed { action: action.name, confidence: 0.8 }),
            EscalationLevel::OrchestratorReport =>
                Ok(ActionResult::NeedsReview { action: action.name, reason: "Review required".into() }),
            _ => Err(GovernanceError::EscalationRequired {
                level: "human".into(),
                context: format!("'{}' needs approval", action.name),
            }),
        }
    }
}

Summary

Festival Principle	AI Agent Design	Rust Implementation
Neighborhood zones	Bounded Autonomy	ResourceBounds + PermissionScope
Graduated reporting	Graduated Escalation	EscalationEngine + RiskLevel
Oral tradition & customs	Contextual Memory	Episode + Rule + recall()
Elder's final judgment	Human-in-the-loop	EscalationLevel::HumanEscalation

The elder told me: "The festival has lasted 1,300 years not because anyone is in charge. It works because the system itself is what's remarkable."

AI agents are no different. No single AI needs to be omniscient. The right boundaries, graduated escalation, and accumulated contextual memory — together, these create truly trustworthy AI agent systems.

Ko Takahashi — Entrepreneur, Philosopher, Engineer. CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform. Exploring the fusion of Japanese culture and technology. ko-takahashi.jp

Forem: Ko Takahashi

Two 'we trust you' partnerships arrived as our design matured. Here's what changed in our technical decisions.

What changes when partnerships arrive at design-maturity

❌ Failure mode 1: over-engineering for the partner you imagine

❌ Failure mode 2: hard-coding a single partner's requirements

What 'audit-ready' actually demands

What changed inside

What I'd love to hear

We're shipping audit-first, federated overseas chapters for our community economy platform. Here's the architecture.

Two design choices, one philosophy

1. Federated parallel chapters

2. Audit as precondition

Invariants documented

Threat model documented

Boundary made auditable

Cross-border hooks (kept out of core)

What this means for who's reading

Discussion

We shipped 3 features in one flow today: Shop + Crowdfunding + Live. Here's the integration design.

The integration target

1. Data model: Liveable as a first-class union

2. Primary metric: totalGmv, not concurrent viewers

3. Checkout inside the stream: 3 taps, no exit

4. Native app: web is the source of truth

5. Why we didn't 'launch' today

What I'd love to hear

I'm shipping a community-run economic platform next month. Here's what we cut, what we kept, and why.

1. We collapsed 4 apps into 1 platform

2. We're avoiding 'follower count' as a primary metric

3. Live streaming is modeled as an economic event, not a broadcast

4. We chose 'parallel cultures' over 'i18n localization'

5. We optimize for circulation depth, not DAU

Why I'm writing this now

I Got Arrogant. I Lost Everything. And Yet Here I Am, Standing at the Gate — A Reflection from 7 Years of Code

Chapter 1 | At Eleven, I Walked Out of School

Chapter 2 | Ages 18–23, I Was Insufferable

Chapter 3 | At 23, on a Hard Floor in Thailand

Chapter 4 | Seven Invisible Years

Chapter 5 | When Personal Gratitude Became Love for a Culture and the Earth

Chapter 6 | And Yet, I'm Still Standing at the Gate

A Note for Engineers

I went to a startup pitch night on 30 hours of no sleep — what India's tech scene taught me about building

TL;DR

The Setup

What India Is Actually Bringing to the Table in 2026

What I Saw on the Pitch Stage

What This Means If You're Building Solo

1. Design for both India and Japan from day one if you can

2. Talk to Indian engineers about constraints you've never had to think about

3. Respect the long arc

The Embarrassing Part: Solo Developer Health

A Quick Note on Yoga and Meditation, Specifically

Closing

What 10,000 Web3 People From 50 Countries Taught Me About Japan's Real Role — TEAMZ Summit 2026

April 7, Shirokanedai, Tokyo

Geisha, sumo, karate — and not a single ironic gaze

Three hallway conversations, one shared problem

A quiet pond, and the answer that arrived

On the train back, one line in my notes

A question for you

Why I Built Shop, Crowdfunding, and Live Into One Platform — A Festival Economy on Web3

A line I added to a memo two years ago

I built Shop because vendors couldn't sell online

I built Crowdfunding to route capital to the festivals worth saving

I built Live because synchronicity is the soul of a festival

Why all three only make sense together

We finally made it here

The Kami in the Code: Japan's Technology, Past, Present, and the Spirituality That Will Shape Its Future

The "Lost Three Decades" Story Is Half Wrong

A Realistic Map: What Is Japanese Technology Actually Doing Right Now?

What Japan Spent Thirty Years Accumulating Was Depth

The Wall Technology Hit, and the Key Japan Holds

The Case for Optimism Is Structural, Not Emotional

Passionate, But Logical

Our Role: Code as Prayer

What I Learned About DAO Governance From a 1,300-Year-Old Japanese Festival System (TEAMZ Summit 2026)

The Thesis: Festivals Are the Original DAOs

Code: Matsuri-Inspired DAO Governance

Key design decisions inspired by matsuri governance:

What I Saw at TEAMZ: AI x Web3 Is Real Now

1. Data model: `Liveable` as a first-class union

2. Primary metric: `totalGmv`, not concurrent viewers