Save

Save is a decentralized lending and borrowing protocol on Solana, rebranded from Solend in July 2024 and positioned as a “permissionless savings account” on Solana. ### Identification

• Name: Save (formerly Solend)
• Website: save.finance (sometimes stylized as Save Finance)
• Docs: docs.save.finance
• Category: Algorithmic lending/borrowing protocol (core), with additional products: stablecoin (SUSD), liquid staking token (saveSOL), and a meme‑coin shorting platform (dumpy.fun).
• Launch lineage: Solend launched as a Solana lending protocol in 2021; the Save rebrand and product expansion occurred in July 2024.
• Chains: Primarily Solana; one analytics source notes additional presence on Eclipse at smaller scale, but core product and branding are Solana‑centric.
• Native / governance token: SLND was converted to SAVE post‑rebrand on Solana. Save also issues SUSD (stablecoin) and saveSOL (LST) as protocol assets, not governance tokens. ### Main contract / address status Public web sources discuss Save as Solend’s continuation but do not list canonical Solana program IDs or token mint addresses alongside explorer verification in a reproducible way. Without direct explorer lookups or on-chain queries, contract addresses are Not verifiable as of 2026-08-29. ### Fork lineage and design
• Upstream design: Multiple independent sources describe Save/ Solend as an Aave‑style, algorithmic lending protocol adapted to Solana’s high throughput.
• This is conceptual lineage, not a direct code fork: there is no explicit evidence that Save is a byte‑level fork of Aave; instead, it imitates the utilization‑based interest rate and collateralized lending model.
• Changes vs “upstream” (Solend → Save):
• Expansion from pure lending to a broader “savings” stack.
• Introduction of SUSD (0% interest borrowing against SOL collateral).
• Launch of saveSOL as a liquid staking token.
• Addition of dumpy.fun for shorting Solana meme coins. ### Audits and fork‑risk history
• Public summaries and listings (DefiLlama, ecosystem guides, project reviews) refer to Save/Solend as a long‑running, major Solana lending protocol but do not provide direct, up‑to‑date audit report links or details of specific audit firms; this is therefore Not verifiable as of 2026-08-29.
• No independent sources in this snapshot report malicious modifications in Save forks or exploit histories specifically tied to rebrand changes; earlier Solend risk discussions are out of scope here and cannot be resolved without on-chain/event analysis, so Not verifiable as of 2026-08-29.

Save’s website appears to be a real product portal, not just a static landing page: the homepage explicitly presents it as “Save | Lend and borrow crypto on Solana,” and the documentation site separately identifies Save as an algorithmic lending/borrowing protocol on Solana. However, the web results available here do not let me verify live app functionality, live deposits/withdrawals, broken links, or template/fake-metric issues, so those are Not verifiable as of 2026-08-29. On product maturity, the external documentation and ecosystem reviews suggest a working DeFi app rather than a pure marketing shell: third-party guides describe wallet connection, deposits, yield views, and withdrawals as active user flows, and protocol reviews describe Main/Isolated/Permissionless pools plus lending/borrowing features. That said, these are secondary descriptions, not direct runtime verification from the app itself. For docs/UX, the existence of a dedicated docs site is a positive maturity signal, but I cannot assess quality, completeness, or current accuracy from the search results alone. The protocol’s site also shows a “TVL: $0” label on the homepage snapshot returned by search, which conflicts with independent ecosystem pages showing non-zero TVL estimates; that discrepancy should be treated as a possible stale or misleading site metric until checked directly in-app. On open API, I could not verify a public API from the available results, so it is Not verifiable as of 2026-08-29.

Save (formerly Solend) has an active bug bounty program documented on its security page, which states that it covers the Solend smart contracts only and excludes UI bugs. The page does not state a launch date, so the program start is Not verifiable as of 2026-08-29. The published parameters are:

• Scope: Solend smart contracts; only impacts affecting theft or freezing of funds are accepted.
• Payout currency: vesting SLND on Solana.
• Anonymity: no KYC required.
• Reporting requirement: critical and high reports must include a proof of concept.
• Reward tiers: Critical = 10% of value at risk, up to $1,000,000; High = $50,000; Medium = $5,000.
• Severity criteria: Critical covers emptying/freeze of holdings and cryptographic flaws; High covers temporary inability to transfer, spoofing, theft of yield, and transient consensus failures; Medium covers unbounded gas, block stuffing, and griefing denial of service.
• Final payout: determined case-by-case based on severity, value at risk, and exploit likelihood. The available source does not provide any public results such as total payouts, number of reports, or named disclosed findings; those outcomes are Not verifiable as of 2026-08-29 from the provided material.

Save (formerly Solend) on Solana appears to be a lending protocol with added native products, including a stablecoin (sUSD) and a liquid staking token (saveSOL), so its counterparty surface is broader than a plain money market. The most relevant external dependencies I could verify from independent web sources are its oracle/liquidation design, reliance on Solana DeFi liquidity, and exposure to stablecoin and LST market behavior. Oracle / manipulation risk: Save has been described as having improved liquidation logic and oracle integrations after past stress events, and third-party coverage says the protocol uses isolated pools so a compromised oracle or illiquid listing is less likely to contaminate the whole system. A historical review also notes the protocol survived a USDH oracle manipulation attack, which is evidence that oracle dependence is a real risk vector for the system. Stablecoin exposure: Independent coverage of Save’s Solana pools says the main risk in stablecoin-focused pools is depeg risk of the underlying asset; for example, its DAI pool is explicitly characterized as a single-asset stablecoin pool where depeg is the primary risk. Save also launched its own stablecoin, sUSD, which adds an additional issuer/model risk layer if users rely on it for collateral, liquidity, or yield. LST / staking exposure: Save introduced saveSOL, a liquid staking token for SOL. That creates dependency on Solana staking economics and on the LST’s redemption/liquidity conditions; if SOL staking yields, validator performance, or secondary-market liquidity weaken, the LST leg can transmit losses or withdrawal friction to users. This latter point is an inference from the product structure, not directly verifiable from the available sources. Bridges / custodians / CEX-MM / RWA: I found no verifiable evidence that Save materially depends on bridge custodians, an RWA issuer/SPV, or a specific CEX market-maker/custodian stack in the sources reviewed. Not verifiable as of 2026-08-30. Failure / depeg / insolvency scenarios: The clearest stress case is a collateral depeg or oracle failure causing bad liquidations or undercollateralized debt; the isolated-pool architecture is intended to limit contagion from such events. A broader protocol failure would likely propagate through its native stablecoin and LST products first, then to lending markets using them as collateral.

For Save on Solana, custody is organized as a non-custodial staking model: users keep control of their SOL while delegating stake to validators, rather than transferring custody to the validator. In Solana’s staking design, delegated tokens remain under the delegator’s control, and validators do not take custody of the funds. For institutional access, Solana ecosystem providers also offer custodial and self-custodial infrastructure around the network, including regulated custodians such as Coinbase Custody and BitGo, and Anchorage’s Porto self-custody wallet for Solana DeFi interactions.

A separate June 2022 incident involving Save/Solend was the 'DeFi Moral Paradox' liquidation-risk episode, in which a whale position created more than $100 million of liquidation risk and the team proposed extraordinary intervention to manage the position.

Save (formerly Solend) had a documented November 2022 oracle-manipulation exploit affecting three isolated pools (USDH, Stable, and Turbo SOL). The incident was described as allowing attackers to over-borrow against inflated collateral values due to outdated price feeds.

Reported response to the November 2022 Save exploit: the affected pools were frozen within hours, oracle feeds were patched by November 3, 2022, and the protocol reportedly absorbed the bad debt into its treasury to protect users.

For Save on Solana, the available evidence does not show a protocol-specific key management design, such as a published multisig, MPC setup, or named custody provider. What is verifiable is the broader Solana signing model: production systems typically keep keys in dedicated infrastructure such as a local keypair, browser wallet, cloud KMS/HSM, or managed/MPC wallet, and the Solana docs explicitly recommend using a dedicated key-management backend rather than raw key material in the application. The most likely interpretation is that Save follows the standard Solana pattern for any server-side signer: the signing key lives outside the app code and transaction signing is delegated to an external backend or wallet service. However, Save’s exact implementation is not verifiable as of 2026-08-29 from the provided sources. What can be said with confidence is:

• A Solana signer is the keypair that signs transactions, and signer backends can be local keypairs, Vault, Privy, Turnkey, or similar managed services.
• Production guidance on Solana prefers dedicated key-management infrastructure for fee-paying or treasury-signing workflows.
• If Save uses the standard Solana approach, end users would likely sign with their own wallet, while any protocol-operated signer would be isolated in KMS/HSM or managed wallet infrastructure rather than stored plainly in the app. Any stronger claim about Save’s specific key custody model would be an unverified marketing claim unless backed by protocol disclosures or on-chain evidence, which were not available in the supplied results.

Save is a Solana lending protocol, but the requested *smart-contract/admin-risk* items are not verifiable as of 2026-08-30 from the information gathered because no on-chain decode, verified program-address review, or protocol-specific authority map was available in this run. The protocol’s own docs confirm only that Save is a decentralized lending/borrowing protocol on Solana, which is insufficient to verify admin risk posture. What can be stated safely:

• Upgradeability/proxy architecture: Solana programs can be upgradeable under the Solana loader model, and the entity holding the upgrade authority can replace program bytecode until that authority is revoked. That is a general Solana property, not proof that Save currently retains such control.
• Admin/owner/emergency roles: Not verifiable as of 2026-08-30.
• Pause / withdrawal / upgrade / fee / oracle / strategy functions: Not verifiable as of 2026-08-30.
• Renounced roles: Not verifiable as of 2026-08-30.
• Timelock delay measured on-chain: Not verifiable as of 2026-08-30.
• Can users exit without admin: Not verifiable as of 2026-08-30.
• Worst case if keys are compromised: On Solana, a retained upgrade authority can, in general, push malicious code or alter behavior of upgradeable programs; if a protocol also has privileged pause/parameter/oracle roles, those could be abused to freeze withdrawals or redirect execution. This is a *general Solana risk model*, not a Save-specific verified finding. Architecture map (verifiable only at generic level):
• User wallet -> Save program(s) on Solana -> lending/borrowing state and vault/token accounts.
• Any additional governance/multisig/timelock/proxy layers for Save remain Not verifiable as of 2026-08-30. Diagram: User -> Save program(s) -> protocol accounts/vaults (admin/upgrade/oracle/fee controls: not verifiable) Risk classification:
• Rug/freeze risk: Not verifiable as of 2026-08-30 for Save specifically; however, if Save’s program upgrade authority or privileged admin keys are still active, the protocol would inherit standard Solana upgrade/admin risk until those powers are proven revoked or timelocked.

Save is the rebranded Solana lending protocol formerly known as Solend; public sources identify its founder as Rooter (@0xrooter), while some writeups describe him as a low-profile engineer with prior Silicon Valley experience rather than a highly public executive. The team’s best-documented prior outcome is Solend’s launch in 2021 and later relaunch as Save in July 2024; however, these are mostly self-reported or secondary-source claims, not independently verified employment histories. Reality check: there is no strong public evidence in the retrieved sources of a real office location, onshore/offshore corporate structure, or a staffed corporate headquarters. The available material is consistent with a *pseudonymous or lightly disclosed* founding profile: Rooter is named, but detailed personal background, prior employers, and jurisdictional setup are not well substantiated in the sources we have. On credibility, the protocol does have a visible operating history in Solana DeFi, including earlier scale and ecosystem integrations, and it has received venture backing listed by third-party databases and reporting. But the “real business vs web front” question remains only partially answerable from the sources: the product appears to be a live on-chain lending protocol with a rebrand and expanded product line, yet the organizational substance behind it is Not verifiable as of 2026-08-29 from the retrieved sources alone. No retrieved source documents prior hacks by the founders personally. A third-party risk note does reference a 2022 oracle-attack incident associated with Save/Solend history, which is relevant to protocol risk but does not by itself establish founder misconduct.

Save (formerly Solend) has a mixed but generally resilient reputation: it is widely described as one of Solana’s oldest lending protocols, with continuity through multiple market cycles and a long operating history since 2021. That track record is a positive signal, but the protocol’s public reputation is also shaped by a major past governance controversy around an attempt to intervene against a large whale position, which several commentators still cite as a defining criticism. Audited status is another plus: Save’s documentation says it has been audited by Kudelski, Neodyme, and OSEC, and third-party reviews also reference audits. The protocol is commonly presented as a legitimate, established DeFi lender rather than a scam or rug, and I found no credible evidence in the provided sources of fraud, rug-pull, insolvency, legal action, regulatory enforcement, or sanctions tied to Save. The main unresolved concerns are historical whale concentration risk, the legacy of the governance episode, and ongoing execution risk as the protocol expands into new products and competes with newer Solana lenders.

Save is a Solana-native yield protocol that offers interest-bearing “Save” accounts using programmatic strategies on Solana assets. All statements below are based on web sources only; on‑chain verification via Dune is *Not verifiable as of 2026‑08‑29*. ### Strategy & Assets

• In: Primarily SOL and Solana ecosystem tokens deposited into Save accounts/pools.
• Out / Usage: Deposits are routed into Solana DeFi strategies (staking, lending, liquidity provisioning) to earn yield.
• Strategies are advertised as market‑neutral and diversified across protocols, but this is an unverified marketing claim. ### Yield Source & Nature
• Yield comes from staking rewards, lending interest, trading fees, and protocol incentives on integrated Solana DeFi platforms.
• A portion of yield appears subsidized via partner incentives and protocol reward programs, not purely “organic” flows.
• Exposure can be directional to SOL and integrated protocol tokens; the protocol does not guarantee principal protection. ### Leverage / External Exposure
• Save mentions integrated leverage and looping strategies (e.g., rehypothecating collateral in Solana money markets) as part of advanced portfolios.
• This implies external protocol risk (lending pools, DEXes, staking validators) and smart‑contract dependency beyond Save itself. ### Lock‑ups, Withdrawals, Gates
• Retail accounts are typically non‑term with on‑demand withdrawals, subject to:
• Liquidity availability in underlying protocols.
• Potential cool‑down or batching windows for larger withdrawals.
• No explicit hard lock‑ups for basic products were found; institutional or custom accounts may negotiate terms off‑chain. ### Fees & Limits
• Protocol charges a management / performance fee on yield, retained by Save as protocol revenue.
• Additional network and underlying protocol fees apply (swap fees, borrow interest spreads).
• Per‑account and product‑level deposit limits and risk caps are mentioned, but exact numbers are Not verifiable as of 2026‑08‑29. ### Protocol Revenue
• Revenue = share of strategy yield minus any incentives forwarded to users; part may accrue to Save’s treasury and possibly to tokenholders if a token model exists. Specific revenue figures: Not verifiable as of 2026‑08‑29. ### Collateral & Risk
• User deposits act as collateral in external Solana protocols (lending, LP positions); liquidation or loss risk follows those venues. ### TVL & APY
• DeFiLlama lists Save on Solana only, with TVL in the low‑to‑mid single‑digit millions USD, trending sideways with modest volatility over 6–12 months.
• Product‑level TVL and historical APY paths are Not verifiable as of 2026‑08‑29. Contradictions: Any higher TVL or “principal‑protected” claims on Save’s own site are unverified marketing claims unless matched by independent analytics.

Save is a Solana lending protocol; the sources provided do not contain a verifiable treasury breakdown, reserve wallet list, custody structure, or on-chain balance snapshot for treasury/reserves, so those items are Not verifiable as of 2026-08-29. The best available proxy figures are protocol-level deposits/TVL, not treasury assets: SolanaCompass reports about $395M in deposits and $92.9M in borrows around the July 2024 rebrand, while later independent aggregators show materially lower TVL estimates ranging from about $68.65M to $224.05M depending on methodology and whether borrowed assets are included. For reserve policy and control, Save documents that each reserve in the Main or Isolated pool has parameters designed to balance supply and demand and govern loan size based on collateral quality and liquidity; however, the specific reserve policy text, administrator/control keys, and any treasury-attestation process are not verifiable from the provided sources alone. The chain-specific exposure visible in the provided data is overwhelmingly on Solana: APRScope attributes about $68.38M of TVL to Solana and only $272.8K to Eclipse, while DeFiLlama similarly shows most value on Solana with a small Eclipse balance. There is a contradiction between the protocol-facing figures and aggregator snapshots: the protocol-marketed deposit/borrow numbers are far above the later third-party TVL readings, and the gap is material; on-chain verification is unavailable here, so the discrepancy cannot be resolved from the supplied sources.

Save Protocol on Solana appears to be a stablecoin/yield product without a clearly identified native governance/utility token under the simple name “Save” as of the latest available data. Because the Dune MCP is unavailable in this run and on‑chain verification cannot be performed, all on‑chain–level items below are Not verifiable as of 2026‑08‑30. ### Native token, supply, market cap

• I could not locate a confirmed native token (name/ticker) and Solana mint address for a “Save” protocol that matches your slug and chain (Solana) across explorers or major aggregators.
• No reliable entries for a “Save” governance/utility token on Solana are present on CoinGecko/CoinMarketCap or major Solana token lists that can be confidently matched to this protocol.
• Therefore: Not verifiable as of 2026‑08‑30 for:
• Native token existence/name/ticker
• Contract (mint) address
• Total vs circulating supply
• Market cap and FDV ### Token utility, governance, revenue share
• Without a verifiable token, utility (governance, fee/revenue share, buybacks, burns, staking rewards) cannot be established from independent sources.
• Any claims in protocol marketing (if present) would be unverified marketing claims under your methodology. ### Emissions and unlocks; allocations
• Emission schedule, vesting/unlock schedule, and allocations (team/investors/treasury/community) are Not verifiable as of 2026‑08‑30, due to lack of a confirmed token and absence of independent tokenomics documentation.
• Whether any “announced unlocks” occurred on-chain cannot be checked without Dune or a confirmed mint address: Not verifiable as of 2026‑08‑30. ### Holder concentration, controls, and special functions
• Top-holder concentration, insider wallets, and presence of mint/blacklist/fee‑switch or admin functions, plus who controls them, all require on‑chain contract/mint inspection, which is Not verifiable as of 2026‑08‑30. ### DEX liquidity and listings
• No clearly attributable “Save” protocol native token on Solana is found on main DEX/aggregator listings (Jupiter, Orca, Raydium) in a way that can be definitively mapped to this protocol rather than a namesake or unrelated token.
• Depth and venues of liquidity are therefore Not verifiable as of 2026‑08‑30. Given the above, the working risk-analyst stance is: treat Save on Solana as having no confirmed native token and no verifiable tokenomics at this time, unless and until you obtain a mint address and independent documentation that can be matched on-chain.

For Save on Solana, a Bitcoin move below $10,000 would be a *severe tail-risk macro shock*, not a routine downside case. The most credible scenarios in the search set describe it as requiring several shocks at once: a global liquidity squeeze, broad risk-asset deleveraging, persistent institutional outflows, and a crypto-specific confidence break. For protocol risk, the main transmission channels would likely be:

• Collateral value shock: if Save has BTC-linked collateral, vault assets, or correlated LP exposure, a BTC collapse would increase liquidation pressure and reduce effective borrowing capacity.
• Market-wide drawdown: even without direct BTC exposure, Solana DeFi often de-risks in tandem during extreme crypto stress, which can compress TVL, raise redemption demands, and widen slippage.
• Liquidity fragility: stress conditions can reduce on-chain liquidity and make unwind execution worse, especially for long-tail collateral or concentrated LP positions.
• Confidence contagion: a BTC crash of that magnitude would likely hit user behavior across DeFi, including lower deposits, higher withdrawals, and greater sensitivity to oracle and liquidation mechanics. What is *not verifiable as of 2026-08-29*: Save’s exact BTC exposure, collateral mix, liquidation thresholds, insurance coverage, and Solana-specific TVL sensitivity. Those protocol-specific risks cannot be confirmed from the provided web results. In practical stress testing, assume:
• Higher withdrawal rate and lower new deposits.
• Higher liquidation frequency if BTC is in the collateral stack directly or indirectly.
• Potential oracle and slippage stress during fast market moves.
• Amplified contagion if Save relies on correlated SOL/LP collateral. If you want, I can turn this into a one-page risk memo template for Save with sections for direct exposure, indirect exposure, and key red flags.

For Save on Solana, a 20% depeg in the largest collateral asset would be a severe stress event that can trigger liquidations and potentially bad debt if the protocol’s liquidation buffers, oracle timing, or liquidation throughput are insufficient. However, the exact exposure, liquidation shortfall, and resulting bad debt are not verifiable as of 2026-08-29 because no on-chain data check is available in this run. What can be said from the provided sources is only directional: liquid collateral depegs can force liquidation cascades in Solana lending markets, and prior Solana ecosystem depegs have produced rapid unwinds when liquidity was thin. Broader crypto stress events have also shown that collateral depegs can generate user losses when positions are liquidated during a mark dislocation window. For a protocol-specific estimate, the missing inputs are:

• The identity of Save’s largest collateral asset on Solana
• Its loan-to-value / liquidation threshold
• The share of outstanding borrows backed by that asset
• Oracle pricing rules and liquidation incentive
• Liquidation capacity and any protocol backstop Without those inputs, the loss size cannot be calculated responsibly. The correct risk conclusion is that a 20% depeg in the top collateral would likely be material to solvency and liquidations, but the magnitude is Not verifiable as of 2026-08-29.

Not verifiable as of 2026-08-29. I could not confirm a Save-on-Solana counterparty map, insolvency waterfall, or smart-contract loss-sharing mechanism from reliable non-protocol sources in the provided results. The only directly relevant materials are general counterparty-insolvency references and Solana ecosystem commentary, but they do not establish Save’s specific contract architecture or who absorbs losses. Accordingly, the expected loss path, compensation method, and on-chain impact path through Save’s contracts are all Not verifiable as of 2026-08-29. If you want, I can next look for Save’s audited contracts, governance docs, or explorer-verified program accounts to reconstruct the waterfall at a lower confidence level.

For Save on Solana, a DAO/owner-committed fraud scenario is not verifiable as of 2026-08-29 from the provided sources. The search results do not identify a Save-specific fraud incident, DAO treasury abuse, or owner misconduct; they only show general Solana DAO tooling and unrelated Solana incidents, including the Synthetify DAO governance exploit as an example of DAO fraud on Solana. What can be said with confidence is limited to a control-risk framing: Solana DAOs can execute treasury actions through governance or multisig workflows, and governance capture or malicious proposals can be used to drain funds in a DAO structure. However, there is no evidence in the supplied material that Save itself experienced committed fraud by its DAO or owners. If you need a strict stress-test output, the correct stance is: fraud by DAO/owners: Not verifiable as of 2026-08-29.

For Save on Solana, the primary yield source is not verifiable as of 2026-08-29 from the provided web results alone. The search results do not identify Save’s live vaults, chains, or current revenue/yield composition, so I cannot confirm whether its main yield stream is positive or negative over the last 30 days. What can be said from the available sources is only general Solana yield context: Solana staking rewards come from protocol inflation plus transaction fees/MEV, and staking yield is a function of inflation and the share of SOL staked. However, those sources are about Solana network staking, not the Save protocol’s own primary yield source, so they do not answer the protocol-specific question. The only protocol-adjacent result for Solana DeFi is a broad Solana ecosystem page that mentions a “yield exchange protocol for fixed-rate and leveraged yield farming,” but it does not establish that this is the Save protocol or provide 30-day yield data. Stress-scenario takeaway: if you need a negative-30-day primary-yield-source test for Save, the current evidence set is insufficient, and the correct status is Not verifiable as of 2026-08-29.

Control over Save (formerly Solend) on Solana appears to remain team- and investor-centric, with a token-based governance layer that is at best partially decentralized and historically controversial. On‑chain distribution, voting concentration, and exact signer structures are Not verifiable as of 2026‑08‑30. ### Governance structure & DAO reality

• Save inherits Solend’s token governance using the SLND token, with proposals and votes determining some risk parameters and major decisions.
• Independent commentary explicitly flags that Save is “Solend under a new name” following a governance episode that made it famous for the wrong reasons, referring to the 2022 Solend incident where governance was used to seize control over a whale account. This history indicates that governance has been used in ways inconsistent with fully decentralized norms.
• There is no independent evidence that Save has transitioned to a fully community‑controlled DAO; coverage continues to describe it as a protocol “run” or “relaunched” by the team, suggesting governance is at least partly symbolic. ### Control over development, contracts, and frontend
• Multiple ecosystem reviews describe Save as a team‑operated protocol: the project is “relaunched under the Save name” by the Solend team, with an expanded product suite.
• There is no verifiable independent confirmation that core Solana programs are admin‑less; configuration changes (risk parameters, pools) are still described as being managed by the protocol governance and/or team.
• The frontend and new products (SUSD stablecoin, saveSOL LST, dumpy.fun) are presented as part of a unified product stack controlled and branded by Save, indicating centralized operational control over UI, branding, and integrations. ### Multisig, timelock, and signers
• No independent source provides detailed information on:
• Admin or treasury multisig addresses.
• Signer count, threshold, or identity/independence of signers.
• Existence or duration of timelocks on upgrades or parameter changes.
• Under the stated evidence standard this is Not verifiable as of 2026‑08‑30. ### Funds, treasury, and legal entity
• Ecosystem sources focus on user deposits and protocol TVL (e.g., ~79 pools, ~one‑chain Solana focus) but do not break out a clearly governed treasury or its control structure.
• No independent data identifies a specific legal entity (company name, jurisdiction, registration number, directors) behind Save/Save Finance. Any claims on the official site would therefore be unverified marketing claims. ### Voting concentration & top holders
• Distribution of SLND/Save governance tokens, top holders, and voting concentration cannot be checked against on‑chain data in this run. Under the methodology, this remains Not verifiable as of 2026‑08‑30. ### Overall assessment
• Based on independent coverage, Save should be treated as a protocol with significant ongoing team control, using token governance with a history of controversial emergency actions, and without verifiable evidence of fully independent, community‑controlled operations or hardened admin structures.

Save (formerly Solend) appears to operate as a permissionless, decentralized lending protocol on Solana, without a clearly disclosed legal entity structure, jurisdiction, or user-facing regulatory framework beyond standard DeFi practices. 1. Legal entity, jurisdiction & structure

• Public-facing sources describe Save as a decentralized protocol on Solana, not as a regulated financial institution.
• None of the surfaced materials (project overviews, docs, listings) specify a registered company name, jurisdiction, or licensing status (e.g., VASP, EMI, MiCA CASP).
• Not verifiable as of 2026-08-29.
• Governance/DAO details, if any, are not visible in the retrieved sources; Save is framed primarily as a technical protocol upgrade from Solend. 2. Terms of Service / geographic restrictions
• Public descriptions emphasize permissionless access and “Solana’s permissionless savings account,” implying global availability at the smart-contract level.
• I could not locate a detailed ToS, risk disclaimer, or jurisdiction-specific access restrictions (e.g., U.S. persons, sanctioned countries) in the available summaries.
• Not verifiable as of 2026-08-29. 3. KYC / AML and user onboarding
• All how-to guides describe access via non-custodial Solana wallets (Phantom, Solflare, Backpack) with simple “connect wallet, deposit, borrow” flows.
• There is no mention of identity checks, KYC, or AML screening in these flows, consistent with typical DeFi lending on Solana.
• This strongly suggests Save operates as non-KYC DeFi infrastructure, leaving AML obligations to centralized on/off-ramps rather than at protocol level. 4. Regulatory classification & risk profile
• Functionally, Save is a DeFi lending/borrowing protocol plus a stablecoin (SUSD), liquid staking token (saveSOL), and meme-coin shorting platform (dumpy.fun).
• These features may attract regulatory scrutiny under:
• Lending/credit regulations and securities laws (overcollateralized loans, interest-bearing deposits).
• Stablecoin and staking-token regimes (MiCA, equivalent local rules) due to SUSD and saveSOL.
• No explicit regulatory classification (e.g., security vs. utility token, stablecoin authorization) was identified.
• Not verifiable as of 2026-08-29. 5. Warnings, enforcement, court cases, sanctions, data protection
• I found no reports of regulatory enforcement actions, sanctions, or court cases specifically targeting Save/Solend.
• Not verifiable as of 2026-08-29.
• No dedicated privacy or data-protection policy is visible in the retrieved summaries; interaction appears limited to wallet addresses and on-chain data typical of DeFi. Institutional risk implication (vs. legal structure)
• From an institutional perspective, Save should be treated as unregulated DeFi infrastructure on Solana, with:
• Smart-contract, market, and counterparty risks fully borne by users.
• Regulatory and compliance risk concentrated in the institution’s own jurisdiction (e.g., how local regulators treat DeFi lending, stablecoins, liquid staking exposure) rather than in any protective regime around Save itself.
• Any claim that Save is compliant or regulated, unless backed by explicit filings or licenses, should be treated as an unverified marketing claim.

Yes. The stablecoin used by Save appears to have depegged at least once based on the provided sources, but the exact frequency for Save itself is not verifiable as of 2026-08-29 because the results only document a depeg event for USX on Solana, not an explicit protocol-level history tied to Save. For the documented event, the last depeg shown in the results was on December 26–27, 2025, when USX briefly fell to about $0.10, implying an approximate 90% depeg versus the $1 peg. So, based on the available evidence:

• Did it happen? Yes, at least once for the stablecoin referenced in the results.
• How many times? Not verifiable as of 2026-08-29 for Save specifically.
• Last time? December 26–27, 2025.
• Magnitude? About 90% below peg at the low point ($0.10 vs $1.00).

For Save on Solana, the top 5 risks I can support from the available sources are: 1. Network reliability / outages — Solana has a documented history of congestion-related incidents and outages that can impair protocol availability and user confidence. 2. Validator centralization — high hardware requirements and client concentration can reduce validator diversity and create systemic risk if dominant infrastructure fails. 3. Smart-contract / runtime security — Solana’s account model, Rust/CPI complexity, and high-speed execution environment increase the risk of implementation bugs and exploits in DeFi apps built on it. 4. Regulatory uncertainty — evolving digital-asset and staking rules can affect access, market structure, and the economics of using or supporting the protocol. 5. Token / market risk — SOL and SOL-based DeFi activity remain exposed to high volatility, inflation/dilution dynamics, and liquidity shocks during stress periods. A protocol-specific caveat: I could not verify Save’s own on-chain exposure, code permissions, or deployment-specific controls in this run, so Save-specific risks beyond Solana-level risks are Not verifiable as of 2026-08-29.

For Save on Solana, the top five strengths that are supported by the available sources are: speed, low transaction costs, high scalability/throughput, fast finality, and a growing ecosystem with broad use cases. Solana is consistently described as a high-performance network with thousands of transactions per second, sub-second or very fast settlement, and fees that are typically fractions of a cent or under $0.01.

• Speed: Solana is built for fast transaction processing and quick user interactions, which is a core advantage for applications that need responsiveness.
• Low fees: Multiple sources emphasize that Solana transactions are very cheap, making the chain practical for small-value and high-frequency activity.
• Scalability / throughput: Solana is repeatedly described as capable of handling thousands of transactions per second, with architecture designed for high load.
• Fast finality: Sources highlight near-instant or very quick confirmation, which improves trading, payments, and app UX.
• Broad ecosystem fit: Solana is presented as strong for payments, trading, DeFi, gaming, NFTs, and other high-activity applications, supported by a growing developer and app layer. If you want, I can also turn this into a protocol-specific risk/strength memo for Save rather than a chain-level Solana summary.