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

Top comments (0)