> For the complete documentation index, see [llms.txt](https://city-protocol.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://city-protocol.gitbook.io/docs/platform/product-mechanics/how-otps-work/technical-overview.md). # Technical overview How the OTP infrastructure is built: its eight components, how they connect, the portfolios it runs as of September 2026 and what arrives with the next phase. The OTP infrastructure is specified for integrators, auditors and technical due diligence. It is built from eight components: the holder's wallet, a portfolio smart account for each holder, portfolio and chain, two permission validators, an automation signer, an execution service, a bundler, the trading venues and an independent reference price source. The holder is the participant whose wallet owns a portfolio smart account. The products and their lifecycle are set out in [How OTPs work](/docs/platform/product-mechanics/how-otps-work.md) and [Portfolio lifecycle](/docs/platform/product-mechanics/how-otps-work/portfolio-lifecycle.md); the specifications set out the mechanism behind them. Every value in the specifications describes the reviewed configuration as of September 2026. Capabilities of the next phase are marked as such and written in the future tense. ## Components | Component | Role | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Holder wallet | The account owner. It is the root validator of the portfolio smart account, signs permission grants and signs withdrawals. | | Portfolio smart account | A ZeroDev Kernel v3.3 account (ERC-7579 modular) on ERC-4337 EntryPoint v0.7, one for each holder, portfolio and chain. It holds the settlement token and the constituent tokens. | | Permission validators | Two validators installed in the account, **Approval** and **Trade**. Each is bound to the automation signer and carries a call policy, a rate limit and an expiry. | | Automation signer | A server-side key in managed wallet infrastructure. It can sign only UserOperations that satisfy the permission validators. | | Execution service | Reads the account state, quotes the venue, checks prices, builds the trade batch, signs with the automation signer, submits and tracks the result. | | Bundler | Submits UserOperations to the EntryPoint. Gas is sponsored through a policy at the bundler, and the account uses no onchain paymaster. | | Trading venue | A reviewed venue on each chain, such as PancakeSwap V3 on BNB Chain and Aerodrome Slipstream (concentrated liquidity) on Base. | | Reference price source | An independent market that checks every quote before it is signed. | ## How the pieces connect The holder's wallet is the root owner of the portfolio smart account. The execution service reaches the account only through the automation signer, and the automation signer only through the Approval and Trade validators, each scoped by its call policy, rate limit and expiry. For each trade the service reads the account's balances and allowances, quotes the venue and compares the quote with the reference price, then signs the approvals and one atomic trade batch. The bundler carries each UserOperation to the EntryPoint, the EntryPoint executes it from the account through the venue router, and the constituent tokens land in the holder's own account.
The holder wallet owns the portfolio smart account; the execution service's automation signer reaches the account only through the Approval and Trade validators; signed UserOperations pass through the bundler, the EntryPoint and the venue router into the holder's account

How the pieces connect. The holder wallet is the root owner of the portfolio smart account, and the automation signer acts only through the Approval and Trade validators, each scoped by call policy, rate limit and expiry. The bundler and the EntryPoint carry each signed operation to the venue router, and the constituent tokens land in the holder's account.

On Venzo, a holder meets the same machinery as three steps on the product page: create the portfolio account, deposit the settlement token and build the index. The panel states the custody, the execution fee and the minimum buy beneath the steps.
The Start investing panel with its three steps and its custody, execution fee and minimum buy terms called out

The Start investing panel of the Magnificent 7 (MAG7) Portfolio on Venzo, as of 26 September 2026. Creating the portfolio account, depositing and building the index map to the smart account, the deposit and the Buy in the specifications.

## Portfolios as of September 2026 Each portfolio runs on one chain with that chain's settlement token, venue and reference prices, and new portfolios enter the reviewed registry as they are onboarded. | Portfolio | Chain | Settlement token | Venue | Constituents | Reference price | | ------------------------------ | --------- | ---------------- | -------------------- | ------------------ | ----------------------------------------------- | | Magnificent 7 (MAG7) Portfolio | BNB Chain | USDT | PancakeSwap V3 | 7 tokenized stocks | Order-book bid and ask for the bStock/USDT pair | | Fantastic 4 (FAN4) Portfolio | Base | USDC | Aerodrome Slipstream | 4 tokenized stocks | Chainlink USD feed, with a fallback market | | Tesla–SpaceX Portfolio | Base | USDC | Aerodrome Slipstream | 2 tokenized stocks | Chainlink USD feed, with a fallback market |
Portfolio cards grouped by chain, Magnificent 7 on BNB Chain and Fantastic 4 and Tesla–SpaceX on Base, each with constituent circles sized by methodology weight and its settlement token, venue and reference price

Portfolios as of September 2026, grouped by chain, with each portfolio's settlement token, venue and reference price. Circle area is proportional to the methodology weight.

What each chain runs, and how anyone can verify an account onchain, is set out in [Deployments and verification](/docs/platform/product-mechanics/how-otps-work/technical-overview/deployments-and-verification.md). ## Design properties * **No pooled contract:** Each holder's position is the token balances in that holder's own account, and no OTP share token exists. * **Recoverable accounts:** An account address is derived from the owner, the Kernel and EntryPoint versions and the portfolio's account index, so it can be rebuilt without any service database, as set out in [Smart account specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/smart-account-specification.md). * **Bounded delegated authority:** The automation signer acts only through two scoped permissions that expire after 90 days, as set out in [Permission specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/permission-specification.md). * **Atomic baskets:** All swap legs of a trade and the execution fee settle in one UserOperation, or none of them do, as set out in [Trade execution specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/trade-execution-specification.md). * **Prices checked before signing:** Every leg is compared with an independent market before the service signs. The trust boundary this creates is set out in [Security model and trust assumptions](/docs/platform/product-mechanics/how-otps-work/technical-overview/security-model-and-trust-assumptions.md). ## Live and next phase | Capability | Status | | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | | Holder-initiated Buy, Sell and Sell Max | Live | | Owner-signed withdrawal of settlement-token cash | Live | | Manual Rebalance that restores the methodology weights among existing holdings | Available where enabled for the product | | Scheduled constituent changes driven by the methodology | Next phase | | Rebalancing Executor, a revocable session signer bound to a policy | Next phase | | Basket Execution Router, with per-leg price checks in one contract | Next phase | | Additional execution venues | Next phase; each will require a reviewed configuration and a new holder-approved grant | ## Specifications {% content-ref url="/pages/GZfxRkbrMiwd5GiqBhrD" %} [Smart account specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/smart-account-specification.md) {% endcontent-ref %} {% content-ref url="/pages/W80ZMGSncmRpOFC11GWo" %} [Permission specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/permission-specification.md) {% endcontent-ref %} {% content-ref url="/pages/Kt4EvoPNfPg2B6yyXqI1" %} [Trade execution specification](/docs/platform/product-mechanics/how-otps-work/technical-overview/trade-execution-specification.md) {% endcontent-ref %} {% content-ref url="/pages/QhFnRujaa7HgzRoASFBJ" %} [Security model and trust assumptions](/docs/platform/product-mechanics/how-otps-work/technical-overview/security-model-and-trust-assumptions.md) {% endcontent-ref %} {% content-ref url="/pages/Z0Ibn8ZE6NBEE9QG6UoZ" %} [Deployments and verification](/docs/platform/product-mechanics/how-otps-work/technical-overview/deployments-and-verification.md) {% endcontent-ref %}