Why We Built OTP Infrastructure, and What It Makes Possible
The products most people actually buy, index baskets, portfolio trackers and thematic baskets, had no rails onchain. Here is what we built, and why it fits each of them.
City Protocol built OTP infrastructure because the products most people actually buy, index baskets, portfolio trackers and thematic baskets, had no rails onchain. The assets were there. The way to hold them as a managed portfolio, without a pool and without handing over a key, was not.
An Onchain Token Portfolio is a published rule executed in each holder's own account. This post explains what that rule runs on, what a holder gets from it, and why the same rails fit an index product today and a tracker or a thematic basket next.
What was missing when the assets arrived onchain
By 2026 almost every asset an index could hold already existed onchain. Tokenized US stocks trade around the clock on BNB Chain and Base. Treasuries, credit and trading strategies sit in vaults with a price. The asset layer was solved.
The product layer was not. In traditional markets the products people hold are packaged. An index fund, a tracker, a thematic basket. Each one is a rule about which assets to hold and in what proportion, wrapped in a vehicle that holds the assets for you. Onchain, the only wrapper available was the vault, and a vault pools. It takes your deposit, gives you a unit, prices the unit, and rations your exit. That is the right design for a strategy that has to be run as one book. It is the wrong design for a portfolio whose whole point is that you hold the assets.
The gap was a way to run a rule inside an account you own. That is what OTP infrastructure is.
What we built
The architecture has three parts a holder should understand, and a few more that operators do.
The account. Signing in creates an embedded wallet through Privy. Buying a portfolio deploys an ERC-4337 smart account owned by that wallet, and every constituent the portfolio holds sits in that account, on the holder's address, visible on a block explorer. There is no pool because every holder has their own account.
The permission. In the next phase, City Protocol's Rebalancing Executor will be added to the account as a session signer bound to a policy. The policy will allow calls to the constituent contracts and the Basket Execution Router, permit the swap and approval functions the router needs, and deny everything else, including any transfer out and any key export. The holder will be able to remove the signer at any time and the constituents stay where they are. Until then the protocol holds nothing in the account at all.
The rule. Every portfolio runs on a methodology that is published and versioned before the product opens. It names the constituents, the weights at purchase and the public information that changes the constituent list. There is no target weight after purchase and no drift band: weights follow the market and are left to follow it. When the named information appears, a new filing, a disclosed trade or a change to an index rule, the change is published before it executes. In the next phase the executor will compute the trades and the router will settle them atomically, each leg price-checked against a reference and capped for slippage, halting rather than filling if a leg cannot clear. Each change is recorded onchain and listed on the product page.
Around those three sit the pieces an operator needs: an account factory, a delegation module that scopes each permission (next phase), an exit router that unwinds a basket in one transaction, and lifecycle controls for issuing, pausing and retiring a product.
What a holder gets from it
One transaction in. Stablecoins become the constituents at published weights, in the holder's own account.
Nothing pooled, nothing custodied. City Protocol holds no assets, no keys and no withdrawal authority. It holds a permission the holder can revoke.
Changes without decisions. The list changes only on public information the rule names, never on a price move, and every change is visible.
Every constituent on its own. Any one of the tokens can be sold, transferred or held separately, because they are ordinary tokens on the holder's address.
Network fees on portfolio operations can be sponsored, so a holder does not need the chain's native coin.
Why it fits index products
An index is a fixed list of names. On the rails it is bought at the weights the methodology sets, one seventh each for the Magnificent Seven Equal Weight OTP on BNB Chain, and equal weight for the Fantastic Four Index OTP and the Tesla–SpaceX Index OTP on Base. From then on the weights follow the market in every holder's account, and the list changes only if the published constituent rule adds or drops a name. That is the simplest thing the rails can run, and it is why the first products are Index OTPs.
The same methodology can run on more than one chain. The rule does not change. Only the constituents' venue does.
Why it fits portfolio trackers
A tracker holds the disclosed positions of a manager and changes only when a new disclosure is published. The methodology names the filing that triggers it, a quarterly 13F or a disclosed trade, the new constituent set is published before it executes, and the change mirrors the disclosure: the specific position that was added, trimmed or sold, and nothing else. In the next phase the executor will move every enrolled account to the new list. The holder sees the change on the Rebalances tab and can leave before or after it.
The architecture defines this product type as the Guru OTP. It arrives with the next phase and is built on the same account, permission and execution model as an index, with a public disclosure as its only trigger.
Why it fits thematic products
A thematic basket holds whatever meets a rule. The rule is the product. On the rails, a Thematic OTP's methodology states the eligibility test, and the constituent list reconstitutes when the test says a name has entered or left. Because the rule is published and versioned, a holder can read exactly why a name is in the basket, and because the rails do not care what the constituents are, the basket can hold tokenized stocks, vault receipt tokens or anything else with an onchain price.
What we deliberately left out
No pool, so there is nothing to drain and nothing to ration. No unit, because the holder's position is the balances themselves. No target weight after purchase, so there is no drift to correct and no monitor to run. No discretion at execution, because a rule that must be followed can be verified after the fact and a manager's judgement cannot. No custody, because the account is the holder's and the protocol is a signer with a policy.
Those absences are the design. Each one removes something a holder would otherwise have to trust.
Where the rails go next
More constituent types, so a portfolio can hold a yield strategy beside a stock. More chains, since a methodology is chain-agnostic and only its constituents choose the venue. And more issuers, because publishing a methodology on the rails needs no fund, no custodian and no unit price, only a rule and the eligibility to offer it.
Frequently asked questions
- What is an OTP, in one sentence?
- A published, versioned rule about which assets to hold, bought at the weights it names and changed only on public information, held inside each holder's own onchain account.
- How is it different from a vault?
- A vault pools deposits and issues units. An OTP holds the constituents directly in each holder's account. A vault is the right container for a strategy; an OTP is the right container for a portfolio.
- Who can issue a product on the rails?
- Anyone eligible to publish a methodology. The issuer never holds participant assets.
- Which product types are live?
- Index OTPs. The Guru and Thematic types are defined in the architecture and arrive with the next phase, together with the Rebalancing Executor and the Basket Execution Router.
- Can I leave whenever I want?
- Yes. One transaction through the exit router, or one constituent at a time, with no epoch and no queue.
The bottom line
The assets came onchain first. The products people actually hold, index baskets, trackers and themes, needed rails that did not pool, did not custody and did not ask anyone to trust a manager's judgement. City Protocol built those rails, and the first index products are running on them.
Architecture as published in the City Protocol OTP documentation as of September 2026. The Guru and Thematic product types are defined in the architecture and are not yet live. The Rebalancing Executor and Basket Execution Router are on the roadmap. This post is for educational purposes only and does not constitute financial or legal advice or a solicitation to buy or sell any asset. Eligibility checks, KYC and jurisdiction limits apply.
