> For the complete documentation index, see [llms.txt](https://docs.nara.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nara.io/nara-protocol/risks.md). # Risks Nara combines smart contracts with off-chain credit positions, valuation, custody and counterparties. No single control removes those dependencies, and losses or delays are possible. NaraUSD can trade away from $1.00, redemptions can be queued or delayed, positions can lose money, and contracts or operations can fail. Do not treat NaraUSD or NaraUSD+ as cash, an insured deposit, or a guaranteed-return product. Risks are grouped below by where they originate. Within each group, the first row is the most material. ### Credit and settlement This is where most of the risk sits, because the backing is a credit portfolio. | Risk | What can happen | Who is exposed | Controls | | ---------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Borrower credit | A borrower cannot repay, repays late, disputes an obligation or suffers business stress | Insurance Fund first, then NaraUSD+, then NaraUSD | Scorecard underwriting, knock-out gates, per-borrower limits, draws capped at 80% to 90% of reported volume, 5-day cure and escalation, originator first-loss tranches where negotiated | | Settlement | A payment corridor slows; repayment arrives after the expected window | Liquidity and yield accrual | Settlement-duration and aged-receivable tracking, corridor performance and exception reports | | Concentration | One originator, corridor or obligor is a large share of the book, especially during ramp-up | NaraUSD+ | Draft limits (7% to 15% single borrower, 35% single corridor), IC approval for any ramp-up excess, breach log | | Manager and fund | A third-party fund gates redemptions, changes strategy or loses value | Liquidity and NAV | DDQ, capacity limit, exit plan, redemption terms known at underwriting | | Valuation | NAV or reported yield overstates recoverability | NaraUSD+ (mispriced entries and exits) | Realized versus accrued separation, monthly reconciliation, three-stage NAV verification, on-chain mint cap | ### Liquidity and exit | Risk | What can happen | Who is exposed | Controls | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Redemption delay | Requests exceed the liquid buffer; queued redemptions take longer than the 7-day target, up to the roughly 30-day notice period of the longest positions | Authorized Users redeeming, and indirectly all holders | Liquid reserve (20% to 35%), liquidity laddering, ordered on-chain queue, redemption stress tests at 20%, 30% and 50% of supply | | Unstaking cooldown | A 7-day cooldown before NaraUSD+ converts; 14 days from NaraUSD+ to stablecoins through the primary route | NaraUSD+ holders | Terms disclosed up front; secondary-market exit available at market price | | Secondary price | NaraUSD or NaraUSD+ trades below backing or below the exchange rate on a DEX | Holders selling on secondary venues | Primary redemption at 1:1 for Authorized Users anchors the price; secondary depth is not guaranteed | | Stablecoin | A reserve or collateral stablecoin depegs, freezes or becomes illiquid | Backing and redemptions | Single-stablecoin limit of 50% to 70% of NAV, issuer and chain monitoring, emergency conversion procedures | ### Protocol and administration | Risk | What can happen | Who is exposed | Controls | | ------------------ | -------------------------------------------------------------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Smart contract | A bug or exploit in NaraUSD, the staking vault, the OFT layer or a reserve venue causes loss | All holders | Paladin and Cantina audits, allowlisted vault operations, unbacked-mint cap, continuous invariant monitoring, emergency pause, planned bug bounty | | Admin and operator | A privileged key is compromised or misused; a signer makes an error | All holders | No single-key privileges; 3-of-5 hardware multisig; maker → reviewer → executor on every action; live-call signing with identity challenges; hard-coded 2-day vetoable timelock on the mint cap; pause-only emergency role | | Custody and wallet | A wrong address, an unauthorized transfer, an unreconciled movement | Backing | Whitelisted destinations, enhanced review of address changes, segregated wallets, daily and month-end reconciliation | | Omnichain | LayerZero messaging or a destination chain fails or is paused | Holders on the affected chain | Burn-and-mint supply conservation, 3-of-5 governed per-chain configuration, rate limits, cross-chain supply monitoring | | Operational | A process, report or reconciliation fails; key-person dependency | All holders | Documented procedures, exception logs, incident runbook, continuity planning | ### External | Risk | What can happen | Who is exposed | Controls | | -------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Legal and regulatory | Product treatment, marketing rules, sanctions or licensing change; access is restricted in some jurisdictions | Users in affected jurisdictions; protocol operations | Panamanian legal opinion (April 2026) covering issuance, staking and the offering; KYC/KYB and restricted-jurisdiction controls; ongoing counsel monitoring. The opinion is jurisdiction-specific, not a global regulatory conclusion | | Reputational | A counterparty or borrower fails publicly; communication lags events | All holders | Documented diligence, escalation procedures, facts-before-conclusions disclosure | ### Risks compound A corridor disruption can delay repayment, push redemptions onto the liquid buffer, and pressure the secondary price at the same time. The stress scenarios below are designed to show that behaviour rather than assume it away. ### Stress scenarios reported to holders Nara reports these tests as operating data supports them. | Scenario | Example test | What holders should see | | -------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------- | | Borrower delay | The largest borrower repays 7, 14 or 30 days late | Impact on liquidity, yield accrual, reserves and redemption capacity | | Redemption spike | 20%, 30% and 50% of NaraUSD requests redemption in one week | Reserve usage, payout timing, any gating logic | | Stablecoin depeg | A major stablecoin marks down 1%, 3% or 5% | Reserve impact, conversion actions, waterfall effect | | Protocol illiquidity | Reserve-venue withdrawals delayed 3 to 7 days | Immediate gap and alternative liquidity sources | | Credit impairment | 5%, 10% or 20% impairment of the PayFi book | Loss allocation across the Insurance Fund, NaraUSD+ and NaraUSD | ### If something goes wrong Nara communicates facts before conclusions: what happened, what is known, what is not yet known, the immediate control action, and a follow-up timeline. A borrower delay, protocol issue, depeg or wallet incident is not called immaterial before the facts are reviewed. If a process is suspended, a report delayed, new exposure paused or a limit changed, that is stated directly. Material incidents are recorded in the incident log on the [Transparency](https://docs.nara.io/nara-protocol/transparency) page. ### Controls reduce risk; they do not eliminate it Underwriting, limits, the liquid reserve, the Insurance Fund, multisig and timelock controls, and audits constrain specific failures. They cannot guarantee the value or availability of off-chain assets, the timing of repayment, continuous liquidity, or a fixed return. | Disclaimer | Detail | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | No insurance | NaraUSD and NaraUSD+ are not insured by any government scheme. The Insurance Fund is protocol capital in first loss, not third-party insurance | | No guaranteed returns | Yield is variable and depends on borrower performance, settlement timing, credit losses and the reserve mix | | As-is basis | The protocol is provided without warranties, under the [Terms of Use](https://docs.nara.io/resources/legal/terms-of-use) | | Your responsibility | You are responsible for your own decisions, for sizing positions to your risk tolerance, and for compliance with the laws of your jurisdiction | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nara.io/nara-protocol/risks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.