Tokenise Tokyo

Demo

About

Tokenize Tokyo is an RWA tokenization platform that puts Japan’s idle city spaces back to work. Instead of tokenizing a whole building, it turns a rooftop, a vacant floor or a parking bay into scoped, time-bounded usage and revenue rights: programmable, composable primitives that can be funded, traded, and managed on-chain. A rooftop could host solar panels. A vacant building could become a workshop. A parking space could serve a neighborhood business. Each opportunity needs clear agreements about the space, its purpose, its availability, and how income is shared. Tokenize Tokyo models each of these agreements as one such right. This is a Japanese social problem before it is a Web3 use case. Tokyo alone counted 896,500 vacant homes in the 2023 housing survey, its 23 wards reported 1,303 hectares of unused land in 2021, and only about 6% of detached houses had rooftop solar in FY2022. Aging owners, shrinking households and the cost of negotiating every arrangement one by one keep these spaces dormant while the city needs housing, renewable energy and room for neighborhood business. Tokenize Tokyo uses programmable rights to lower that coordination cost: an owner can share one use of a space without selling it, and the community can fund and operate it. Our application connects four workflows: tokenize your own asset, acquire rights in someone else’s project, manage your holdings, and monitor operations through a dashboard. For example, an owner can propose a rooftop solar project, define revenue-sharing units, and offer them to supporters. Holders can resell transferable units, claim revenue actually deposited into the project’s vault, or combine compatible revenue rights into custody-backed baskets. Once these rights are on-chain, four things become programmable. Ownership carries its own scope, purpose, period and transfer policy, and the contract rejects conflicting exclusive uses at issuance. Transactions settle rights and payment atomically, and transfer checkpoints keep income already accrued with the previous holder. Permissions are delegated through ENSv2 with limits on purpose, time and quantity, and can be revoked. Financial workflows compose: compatible revenue rights can be deposited into custody-backed baskets and redeemed for the underlying units. The dashboard connects these actions to operational data: funding progress, activation status, trading volume, deposited revenue, distributions, and transaction history. Charts help users understand both their holdings and activity across the platform. ENSv2 gives a connected space a hierarchical identity and revocable permissions for delegated work. An owner can authorize an operator to issue rights within defined limits, or authorize a reporter to update only an energy-report record. Tokyo is our starting point. City previews for New York and Hong Kong illustrate how the same model could extend to other cities. The live prototype runs on Sepolia using fictional properties, simulated property verification, and valueless test tokens. A separate wallet-free demo is available at /demo. Lending and collateral borrowing are presented as Coming soon.

How it's made

I built the frontend with Next.js, React, TypeScript, and MapLibre, using OpenFreeMap for the city basemap. Solidity contracts, developed and tested with Foundry, implement asset registration, verification, ERC-1155 rights, fixed-price trading, revenue distribution, and custody-backed baskets. Each right records its spatial scope, purpose, time window, supply, and transfer policy. Marketplace purchases exchange rights and MockJPY atomically. RevenueVault uses transfer checkpoints to preserve income already accrued to previous holders. BasketVault holds the underlying rights and supports share issuance and redemption. Curvegrid MultiBaas connects the application to these contracts. Foundry deploys the contracts; Forge MultiBaas and our linking scripts register their ABIs, addresses, and indexing configuration. The frontend uses MultiBaas for ABI-backed contract reads, unsigned transaction composition, event queries, dashboard aggregates, and receipt monitoring. Users approve transactions through their wallets. This let us build the market and operational dashboard without maintaining a separate event-indexing service. Curvegrid integration code: - [src/lib/multibaas.ts](https://github.com/natsukingly/tokenize-tokyo/blob/main/src/lib/multibaas.ts) - [src/lib/queries.ts](https://github.com/natsukingly/tokenize-tokyo/blob/main/src/lib/queries.ts) - [src/lib/projection.ts](https://github.com/natsukingly/tokenize-tokyo/blob/main/src/lib/projection.ts) - [contracts/script/Link.s.sol](https://github.com/natsukingly/tokenize-tokyo/blob/main/contracts/script/Link.s.sol) Our ENSv2 integration uses the official Sepolia hierarchical registries and Permissioned Resolver. UrbanNamespaceAuthority validates the registered namespace’s binding to a specific asset and scope. Delegated issuance requires both an ENS role and an owner-defined application grant, with purpose, time, and quantity limits. A separate reporter permission allows updates only to `urban.energyReport` on a dedicated rooftop resolver. Reports are read through Universal Resolver V2, and revocation prevents further writes. ENS integration code: - [contracts/src/UrbanNamespaceAuthority.sol](https://github.com/natsukingly/tokenize-tokyo/blob/main/contracts/src/UrbanNamespaceAuthority.sol) - [contracts/src/UrbanRightToken.sol](https://github.com/natsukingly/tokenize-tokyo/blob/main/contracts/src/UrbanRightToken.sol) - [src/lib/ens/reports.ts](https://github.com/natsukingly/tokenize-tokyo/blob/main/src/lib/ens/reports.ts) - [Live ENSv2 permissions demo](https://tokenize-tokyo.vercel.app/ens) Notable engineering work includes validating composed transaction calldata before signing, handling MultiBaas pagination and indexing delays, and combining verified historical logs with newly indexed events without double counting. I use Foundry, Vitest, and Playwright to check contract permissions, accounting, data projection, and browser workflows. Public transaction receipts provide reproducible evidence of the testnet flows.