> For the complete documentation index, see [llms.txt](https://nysa-finance.gitbook.io/nysa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nysa-finance.gitbook.io/nysa/architecture/risk-framework/product-risks.md).

# Product Risks

## Product Risks

Product risks arise from the protocol as a software artifact — the smart contracts, front-end, administrative access, and external data dependencies that make up the system. Because Nysa deploys on pre-existing, heavily audited infrastructure, many of the highest-severity smart contract risks are inherited from codebases with years of production hardening. Nysa's product risk work focuses on what we add on top: deployment configuration, front-end security, admin key management, and oracle integration.

***

### 1. Smart Contract Risks

#### What can go wrong

Vulnerabilities in the smart contract layer — whether in the underlying protocol (Aave V3, Euler V2) or in Nysa's deployment configuration — could lead to loss or theft of user funds. This includes reentrancy, logic errors, misconfigured parameters, and upgrade-related bugs.

#### How we mitigate it

**Pre-audited infrastructure.** Nysa does not build lending protocols from scratch. Every market runs on one of two battle-tested codebases:

* **Aave V3** — Aave V3 instances are deployed as integral forks of the Aave V3.0 codebase, inheriting its full audit history (OpenZeppelin, Trail of Bits, Certora, SigmaPrime) and years of production track record securing billions in TVL.
* **Euler Vault Kit (EVK)** — Euler V2 instances are deployed through the EVK factory, inheriting its audit history and formal verification suite.

Nysa does not modify core protocol logic in either case.

**Deployment-configuration audit.** What Nysa does control — parameter calibration, oracle adapter wiring, market configuration — undergoes its own dedicated audit process before every mainnet deployment.

**Formal verification.** Critical invariants (solvency, collateral accounting, liquidation thresholds) are formally verified using Certora or equivalent tools, both at the infrastructure level (inherited) and at the configuration level (Nysa-specific).

**Testing.** Every market is deployed and stress-tested on forked testnets before mainnet launch. This includes unit testing, integration testing, fuzzing, and adversarial scenario simulation.

***

### 2. Front-End Risks

#### What can go wrong

The front-end is the layer most users interact with directly. Compromises here — DNS hijacking, CDN injection, phishing clones, or XSS vulnerabilities — could trick users into signing malicious transactions, even when the underlying smart contracts are secure.

#### How we mitigate it

**Hosting and DNS security.** The front-end is served through infrastructure with DNSSEC enabled and access controls on deployment pipelines. No single individual can push a front-end update to production unilaterally.

**Content integrity.** Subresource Integrity (SRI) hashes and Content Security Policy (CSP) headers prevent injection of unauthorized scripts.

**Transaction simulation.** The front-end integrates transaction simulation so users can preview the exact on-chain effect of their action before signing, catching any discrepancy between what the UI shows and what the contract will execute.

**Open-source front-end.** The front-end codebase is open source, allowing community review and independent verification.

***

### 3. Admin Key Risks

#### What can go wrong

Protocols with powerful admin keys create a single point of failure: if a private key is compromised, an attacker could drain funds, change risk parameters, pause markets, or upgrade contracts maliciously. Even without compromise, excessive admin power undermines the trust assumptions of a decentralized protocol.

#### How we mitigate it

**Multi-signature governance.** All administrative actions — parameter changes, market deployments, emergency pauses — require multi-sig approval. No single key holder can execute a privileged operation alone.

**Timelocks.** Non-emergency parameter changes are subject to a timelock delay, giving users and monitoring systems time to detect and react to any unexpected change before it takes effect.

**Minimal admin surface.** Admin permissions are scoped to the minimum necessary for each role. Core protocol logic (inherited from Aave V3 or Euler V2) is not upgradeable by Nysa — only market-level configuration parameters are within Nysa's admin scope.

**Key management.** Signing keys are stored in hardware wallets with no single point of compromise.

***

### 4. Price Feed Manipulation

#### What can go wrong

Lending protocols depend on accurate, real-time price data to calculate collateral values and trigger liquidations. If an oracle reports a manipulated or stale price, borrowers could be liquidated unfairly, or attackers could borrow against artificially inflated collateral — draining the market before the price corrects.

#### How we mitigate it

**Tier-A oracles only.** Nysa uses exclusively Chainlink and equivalent institutional-grade price feeds — never custom oracles, TWAP from low-liquidity DEX pools, or single-source feeds.

**Deviation and heartbeat checks.** Each price feed is configured with maximum deviation thresholds and heartbeat intervals. If a feed deviates beyond tolerance or fails to update within the expected window, the affected market operations are automatically paused.

**Circuit breakers.** Our monitoring infrastructure (OpenZeppelin) watches every price feed in real time. Anomalous price movements — even within tolerance bounds — trigger alerts and can activate circuit breakers that freeze affected markets until the situation is assessed.

**No single oracle dependency.** Where available, price feeds are cross-referenced against secondary sources. A single oracle failure does not silently propagate into liquidation decisions.