The Tokenomics of Onchain Yield Coin (ONYC)

ONYC is a NAV token for a regulated reinsurance pool, not an emissions game

ONyc (ticker: ONYC) is structurally closer to a tokenized fund share than a DeFi “yield token.” Each token represents a proportional claim on a regulated segregated account that underwrites short-duration insurance and reinsurance contracts, with the token’s net asset value (NAV) updating to reflect premiums earned and claims incurred. For a different RWA-style reference point, compare with reUSD tokenomics.

Two details in the tokenized reinsurance docs matter for mechanism design.

First, value accrues primarily through NAV appreciation rather than user-side “staking” distributions. The docs are explicit that ONyc is designed to be an appreciating asset driven by real-world cash flows, and it is not intended to behave like a stablecoin with a fixed $1 peg. For a stablecoin-style contrast, see Frax USD tokenomics.

Second, the project’s “tokenomics” is mostly about issuance, redemption, NAV publication, and liquidity control loops. That is where the real policy levers sit.

Access is split into “Open Access” and “Institutional Access.” Open Access is presented as permissionless acquisition, while Institutional Access involves KYC/KYB workflows aligned to OnRe’s regulated entities.

Jurisdiction gating is not a footnote. The docs list the United States among the excluded jurisdictions list for ONyc. That restriction is a hard constraint on distribution, liquidity depth, and how “permissionless” can be in practice.

Supply, issuance, and the closest thing ONYC has to an “emissions schedule”

ONyc does not present as a fixed-supply asset with a pre-mined allocation table. Supply is demand-driven: users mint by depositing supported collateral, and redeem back into supported stablecoins.

CoinGecko lists ONYC with max supply = ∞, which matches the “fund-share” mental model. If the pool grows, the token supply can grow. If redemptions dominate, supply can contract.

On Solana, the docs specify the ONyc SPL mint address as 5Y8NV33Vv7WbnLfq3zBcKSdYPrk7g2KoiQoe7M2tcxp5.

Minting inputs are currently limited to USDC and USDG. The project states other assets may be added later.

Fees at issuance and redemption are simple on paper.

Minting “carries no mint fee” (network fees still apply).

Redemptions through the online application charge 10 basis points on fulfilled redemptions, and that parameter is explicitly “subject to change.”

The more subtle “emissions-like” component is not token inflation. It is price-path definition inside the mint/redeem program.

OnRe’s Solana program is built around “offers” for token exchanges (for example, USDC → ONyc) and uses time-based pricing vectors. The docs spell out a discrete-interval pricing model with APR-based growth:

price = base_price * (1 + apr * effective_time / SECONDS_IN_YEAR), where base_price uses 9 decimals and apr is scaled by 1,000,000, as specified in the integration reference doc.

This is good engineering hygiene. It is deterministic given parameters. It is also a reminder that parameter-setting is where governance risk concentrates, even if the formula is clean.

One more constraint worth calling out. The same technical doc notes the program state includes a kill switch. That is operationally prudent. It is also a centralized control plane by definition.

No public documentation I found provides a classic “token allocation” breakdown (team, investors, treasury) in percentages. That omission is consistent with an on-demand issuance model, but it reduces external modelability around who can dominate liquidity and how secondary-market support might be prioritized.

Utility and fiscal flows: where yield comes from, and how it reaches holders

ONyc’s return stream is a blend of (1) reinsurance premiums and (2) collateral returns. The docs explicitly separate “Reinsurance Premiums” from “Collateral Returns” as distinct yield components.

The token’s design goal is that these drivers are visible through a transparency framework, with NAV updated daily and streamed via independent oracles.

How does yield accrue to users in token terms.

OnRe’s FAQ states ONyc is a non-rebasing token, with yield accruing through changes in NAV over time, realized on redemption or via secondary liquidity.

That matters. Non-rebasing NAV tokens tend to integrate more cleanly across DeFi because balances do not change under you. The accounting complexity shifts into price/NAV feeds and valuation logic.

There is some wording tension in the Minting doc, which says “ONyc supply grows” via a “daily auto-compounding mechanism.” I would treat the FAQ as the higher-precision statement for integrators. If the token is truly non-rebasing, “auto-compounding” should mean NAV movement, not balance rebases.

Protocol-side revenue is described as (i) profit share on pool performance and (ii) underwriting commission on reinsurance placements, with revenue distributed proportionally based on tokenized share ownership.

In DeFi, ONyc utility is straightforward. Hold, LP it, post it as collateral, loop it. The project is explicitly steering it toward “collateral-grade” usage across Solana venues.

The incentive layer is not emissions of ONYC. It is points.

OnRe Points are awarded based on a published formula that multiplies ONyc-equivalent balance by time held and by strategy multipliers. The doc provides an explicit per-position formula including tier, leverage, and campaign multipliers, normalized by 86,400 seconds per day. For a Solana-native incentive comparison, see Jito tokenomics review.

As a mechanism designer, I like that the points math is stated. I dislike that campaign multipliers are, by definition, discretionary. Points systems can become shadow monetary policy if they end up gating future economic benefits.

Liquidity design: redemption scheduling, NAV anchoring, and buyback loops

ONyc is trying to sit in two worlds at once.

World A is a real-world underwriting book with contractual cash flows and event-driven losses. World B is 24/7 onchain liquidity and collateralized leverage, where liquidity gaps become liquidations.

The docs describe a dual liquidity model: (1) scheduled redemptions and (2) secondary market liquidity on DEXs.

Redemptions have historically been described as quarterly cycles with notice windows and pro-rata fulfillment if requests exceed the “available amount.”

The more recent Capital Providers redemption doc indicates a structural shift. It says that beginning in 2026, primary-market redemptions are processed digitally, and it introduces explicit capacity targets like reserving up to 20% of underwriting capital for redemptions and weekly redemption capacity up to 2.5% of NAV (both framed as targets that may change) in the redemption capacity targets.

This is the correct direction for DeFi composability. It is also where the liquidity promise can break first under stress, because targets are not hard constraints.

Secondary market behavior is supported by explicit “treasury and liquidity management mechanisms” and by a market-making bot described as actively arbitraging price differences to keep price close to NAV.

Buybacks are documented as a distinct lever. ONyc buybacks are positioned as a liquidity management tool to support secondary market efficiency and maintain a tight relationship between market price and NAV. They are also stated to be discretionary and “policy-driven,” with execution depending on market conditions and treasury capacity.

Funding sources for buybacks are described as protocol operating revenue, underwriting premiums allocated to the liquidity layer, and treasury reserves.

This is the main trade-off in ONyc’s market design.

Deterministic rule sets make collateral assets legible. Discretionary “stabilization” improves outcomes in benign regimes but weakens worst-case guarantees. If buybacks are central to keeping ONyc close to NAV during drawdowns, then ONyc is implicitly depending on a human-run treasury desk when it matters most.

Governance and parameter control: transparent formulas, centralized keys

ONyc’s onchain surface area is stronger than most RWA tokens. It publishes addresses, program IDs, and oracle architecture. That is good. It also makes it very clear where the admin keys sit.

The Token Configuration doc enumerates key control points, including:

Solana Program: onreuGhHHgVzMWSkj2oQDLDtvvGvoepBPkqyaubFcwe

ONyc Mint Authority: onreuGhHHgVzMWSkj2oQDLDtvvGvoepBPkqyaubFcwe

Program Upgrade Authority: onREP1E8Yk7p83fRFeApZSTN1vCzdfZKzS46dWErsre

Those are crisp disclosures. They are also a reminder that minting is ultimately controlled by the program, and the program itself can be upgraded by a designated authority in the token configuration doc.

The Smart Contract Integration doc is unusually direct about operational controls. It states the program state contains “boss, kill switch, approvers.”

From a mechanism design perspective, that is a centralized governance model with transparent interfaces. There is no claim in the primary docs that ONYC holders govern parameters onchain. The “governance” described in the whitepaper is closer to fund-manager controls, including minting and burning, issuance and redemption, and NAV price feeds, secured by a multisig.

Oracle architecture is also clearly defined. ONyc uses Pyth for high-frequency market pricing and Chainlink for NAV publication and structured reference data, with the ONyc smart contract treated as the canonical onchain source of truth for NAV and product state.

This is a sane separation of concerns. Spot price feeds for liquidations. NAV feeds for conservative valuation anchors. Still, NAV ultimately depends on offchain reality and offchain processes. Oracles can publish, but they cannot prove underwriting quality.

Risk analysis: ONYC’s design is legible, but the dominant risk is discretionary control over collateral-grade behavior

ONyc is doing real engineering work to become “collateral.” That is the right ambition. It is also where weak guarantees get punished.

Top 3 risks

1. Admin and policy discretion risk (dominant). Trigger: a stress regime where ONyc trades materially away from NAV or where portfolio conditions require rapid parameter changes. Mechanism: centralized controls over program upgrades, kill switch behavior, offer configuration, redemption settings, and discretionary buybacks can change system behavior faster than integrators can re-model it. Who bears it: leveraged users and protocols that accept ONyc as collateral, plus passive holders exposed to governance-driven execution quality. Measurable indicators: frequency and magnitude of parameter changes (offer vectors, fees, redemption settings), periods of persistent price-to-NAV deviation, and observable buyback activity versus stated objectives. For examples of indicator-driven monitoring, see our research reports.

2. Liquidity mismatch and redemption queue risk. Trigger: elevated redemption demand coincident with reduced secondary liquidity, or temporary shortage of redeemable stablecoins. Mechanism: redemptions are explicitly constrained by available capital and can remain pending until liquidity is available, with capacity described in targets rather than hard guarantees. Who bears it: holders relying on primary-market exits, and protocols assuming redemption arbitrage will close NAV gaps. Measurable indicators: pending redemption queue size (if publicly observable), redemption fulfillment delays, and changes to stated redemption capacity targets.

3. Underwriting and claims shock risk. Trigger: adverse loss events that exceed reserves or forecasted loss ratios for the portfolio’s risk periods. Mechanism: reinsurance risk is event-driven and contractual. Losses can reduce NAV through claims and reserve adjustments, which then propagates into collateral valuation and liquidation thresholds across DeFi venues. Who bears it: all holders through NAV drawdown, and especially leveraged users via liquidation cascades. Measurable indicators: NAV drawdowns, reserve adjustment disclosures, and claims activity reflected in daily NAV updates.

Dominant risk: discretionary control over “collateral-grade” guarantees

The design is transparent enough that you can see the moving parts. That is a real advantage. But the system is not governed by immutable constraints.

Start with the smart contract layer. The program state includes a kill switch, and the program has an upgrade authority. Those are standard safety mechanisms. In a collateral context, they also create a “what happens during halt” question for every integrator. If liquidations depend on continuous price feeds and continuous transferability, a kill switch is not neutral. It is a regime change.

Then the market microstructure layer. The docs explicitly rely on (i) a market-making bot to arbitrage price deviations and (ii) discretionary buybacks funded from operating revenue, allocated premiums, and reserves. That is a managed peg-to-NAV behavior, even if ONyc is not a stablecoin. If it works, it tightens spreads and makes risk models more stable. If it fails, you get a double hit: price dislocation plus uncertainty about whether stabilization will be deployed.

Finally, the redemption layer. The newer redemption doc is directionally strong because it talks about an onchain queue, constrained execution, and explicit capacity targets. It also says settings can be adjusted by authorized administrators. That is exactly the kind of flexibility you want operationally. It is also the kind of flexibility that makes the asset harder to treat as a pure rule-based primitive.

If ONyc is held unlevered, these are mostly governance trust assumptions. If ONyc becomes widely rehypothecated, they become systemic. DeFi treats “liquidity under stress” as part of the definition of collateral. Discretionary tooling can improve expected outcomes while worsening tail guarantees.

The practical conclusion is not that ONyc is “bad.” It is that the token’s safety is a function of operator behavior and policy discipline, not just formula correctness. The formulas are readable. The keys still matter more.

If you are evaluating ONyc for treasury use or as a base asset in a vault, treat it like you would treat a managed fund share that happens to be composable. Model the admin surface area explicitly using a tokenomics methodology. Do not hand-wave it away as “just smart contracts.”

If you need help pressure-testing parameter surfaces and integration incentives, this is the kind of work that fits tokenomics design services. Keep it mechanical. Demand explicit constraints, not aspirations.

This article is part of our Tokenomics Deep Dive series.