§5 · Holding a cohort
Issuer powers and risk
The companies that issue tokenized stocks keep powers over them. Here is what each power can do to a pod, and to you.
The xStocks inside a pod are Token-2022 tokens issued by a company, and the issuer keeps control over them through token extensions. A pod's vault is just another token account, so every power an issuer has over your wallet it also has over the vault. Cohort can't take those powers away. What it can do is refuse issuers it doesn't know, keep each pod's losses inside that pod, and make sure one blocked component never traps the rest of your basket.
Each power, and what it means for you§
| Power | What the issuer can do | What it means for a pod | What the program does |
|---|---|---|---|
| Permanent delegate | Move or burn tokens out of any account, the vault included, without a signature | A seizure lowers the backing of every cohort in that pod | Records the loss as shortfall and shares it pro-rata within that pod only |
| Freeze | Freeze one token account, such as the vault or yours | That component can't move. Wraps fail; a plain unwrap fails | unwrap_partial pays the rest and writes a claim ticket for the frozen part |
| Pause | Stop every transfer of the token, everywhere | Same as a frozen vault, for every pod holding it | Same: partial unwrap and claim tickets. A mint paused at creation is rejected |
| Transfer hook | Run its own program on every transfer, which can require extra accounts or refuse | Wraps and unwraps carry the hook's extra accounts and use more compute | Forwards hook accounts per component. If the hook program changes after the pod is created, new wraps fail with HookChanged and that component may be ticketed |
| ScaledUiAmount | Change a display multiplier for dividends and splits | Raw balances don't change, so neither does share math | Works in raw units only. Interfaces show raw × multiplier |
| Default account state | Make new token accounts start frozen | A new vault would be frozen from birth | create_pod refuses a frozen vault (VaultFrozen) |
Two consequences are worth stating plainly. First, the issuer can take the backing, and if it does you lose that part with everyone else in the pod. Second, a pause or freeze can delay part of your exit for as long as the issuer wants: the claim ticket is good, but only when the token moves again.
The issuer allowlist§
create_pod accepts a component only if every key holding a power over it is on Cohort's issuer allowlist. The keys checked are the freeze authority, the permanent delegate, the pause authority, the transfer-hook authority and the hook program itself. A mint with a transfer fee, or with any extension outside a fixed list, is rejected outright.
The list exists so that a pod can't be built from a token whose powers belong to someone unknown, such as a clone of a real xStock with a stranger as permanent delegate. The protocol admin adds and removes keys. Removing a key only stops new pods; existing pods and every unwrap carry on.
Seizures, shortfall and reconcile§
Every pod has its own vault for every component. When an issuer seizes from one vault, only that pod's books are wrong, and only its holders bear it.
The program spots a seizure by comparison. It expects each vault to hold tracked_balance + claims_outstanding: the backing of the cohort supply plus anything reserved for open claim tickets. If the vault holds less, the gap (up to the whole tracked balance) moves from tracked_balance to shortfall. This check runs at the start of every wrap and unwrap, and anyone can run it on its own with reconcile. It is idempotent.
An example. A pod has 1,000 cohorts and 40 SPYx tracked, so 0.04 SPYx per cohort. The issuer seizes 2 SPYx from the vault. At the next wrap, unwrap or reconcile the program records a shortfall of 2 and a tracked balance of 38, and every cohort is now backed by 0.038 SPYx. That is 5% less SPYx per cohort, the same for every holder, and the other components and every other pod are untouched.
Two details from the program's tests:
- No run on the vault. Because every unwrap syncs first, the first person out after a seizure is paid at the reduced rate, not the old one.
- Claims come first. The deficit is charged to the tracked balance before it can touch tokens reserved for claim tickets. Only a seizure larger than the entire tracked balance could leave a ticket short.
When one component can't move§
A plain unwrap pays every component or fails. If a component is paused, its vault is frozen, your own account for it is frozen, or its hook program has changed since the pod was created, use unwrap_partial. You receive the components that can move now and a claim ticket for your share of each blocked one: an account in your name holding the exact raw amount, reserved in the vault. You redeem it when the component moves again. §6 Partial unwrap and claim tickets walks through it.
What Cohort's admin can and cannot do§
The protocol admin can:
- block new wraps and new pods with
set_wraps_paused; - add and remove issuer allowlist entries;
- mark pods verified or unverified.
The admin cannot pause unwraps, partial unwraps or claim redemptions; change a pod's recipe, fees or protocol share; move anything out of a vault; or mint cohorts. None of the instructions that would allow it exist.
The program itself is upgradeable: initialize_config must be signed by the upgrade authority, so one exists. Whoever holds it can deploy new code, and new code could do anything. Until the program is audited and its upgrade authority is held by a multisig or removed, treat that as the largest power over a pod.
The risks, in plain words§
- Issuer seizure. An issuer can take tokens out of a vault. You lose your share of what it takes.
- Issuer pause or freeze. Part of your basket can be stuck for an unknown time. You can take the rest, but not the stuck part.
- Issuer failure. An xStock is a claim on its issuer and the issuer's custody of the real shares. If that fails, the token may be worth little, and so would the cohort's share of it.
- No shareholder rights. Neither a cohort nor an xStock gives you votes, a share register entry or a claim on the company.
- Price gaps. The cohort's pool price can sit away from its NAV, by more on thin pools and at weekends. Unwrapping is the exit that doesn't depend on it.
- Smart-contract risk. The program is unaudited and upgradeable, and runs on devnet only.
- Thin liquidity. If a component can't be traded at size, arbitrage weakens and the pool price drifts further.
- Small yield. Burns raise backing slowly. See §3 Fees and the burn.
Legal notes§
Not an offer. Nothing in this documentation is an offer to sell, or a solicitation to buy, any security or financial product, and nothing here is investment, legal or tax advice. Cohort is software. It doesn't hold your assets or act as a broker, fund manager or custodian.
Not available to US persons. Cohort is not available to US persons, or to anyone resident or located in any of these places:
- the United States and its territories
- Canada
- the United Kingdom
- Australia
- any country or region subject to comprehensive sanctions (including Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk and Luhansk regions)
The issuers' own terms already restrict xStocks to non-US persons. A cohort is freely transferable on-chain, and wrapping tokenized shares into a pooled token may itself be treated as a security or a pooled investment vehicle in many places. The interface asks you to confirm you are eligible; it can't check, and the responsibility is yours.
Devnet only. The current deployment runs on Solana devnet with mock tokens that have no value. A mainnet deployment would need an audit and a legal review first.