How we apply the US federal government's security controls framework to smart contract security on EVM chains.
This whitepaper describes the methodology used by DeFi Sentinel Watch to apply NIST Special Publication 800-53 Revision 5 (the United States federal government's security controls framework) to decentralized finance (DeFi) protocols on the Flare Network, including SparkDex liquidity pools, Spectra Finance yield tokenization pools, Mystic Finance lending vaults, Kinetic Market lending markets, and the Firelight stXRP liquid staking vault.
We adapt 20 NIST 800-53 security controls to how DeFi protocols are built: AMM liquidity pools, yield tokenization markets, modular lending vaults, Compound-style lending markets, and ERC-4626 liquid staking vaults. This paper covers the on-chain queries, pass/fail criteria, and rating method used in our weekly automated audits.
We are not aware of any other published methodology that applies NIST 800-53 to on-chain smart contract security.
Decentralized finance protocols collectively hold billions of dollars in user assets. Unlike traditional financial institutions, these protocols operate without central governance, regulatory oversight, or mandatory security disclosure requirements. Liquidity providers bear direct security risk with limited tools to assess it.
Traditional security audit firms provide point-in-time assessments costing $10,000–$50,000 per engagement. These audits are valuable but insufficient for continuous security monitoring of live protocols.
We selected NIST 800-53 for three reasons:
| Family | Control | Name |
|---|---|---|
| Access Control | AC-2 | Account Management |
| Access Control | AC-3 | Access Enforcement |
| Access Control | AC-6 | Least Privilege |
| Audit & Accountability | AU-2 | Audit Events |
| Audit & Accountability | AU-6 | Audit Review |
| Audit & Accountability | AU-9 | Protection of Audit Information |
| System & Comm. Protection | SC-5 | DoS Protection |
| System & Comm. Protection | SC-8 | Transmission Integrity |
| System & Info. Integrity | SI-2 | Flaw Remediation |
| System & Info. Integrity | SI-7 | Software Integrity |
| Incident Response | IR-4 | Incident Handling |
| Configuration Management | CM-6 | Configuration Management |
| Risk Assessment | RA-3 | Oracle Integrity |
| Contingency Planning | CP-9 | State Recovery |
| System & Services Acquisition | SA-11 | Security Testing |
| System & Info. Integrity | SI-4 | System Monitoring |
| Incident Response | IR-5 | Incident Monitoring |
| Identification & Auth | IA-3 | Device Authentication |
| System & Comm. Protection | SC-7 | Boundary Protection |
| Risk Assessment | RA-5 | Vulnerability Scanning |
| Contingency Planning | CP-10 | FAssets Agent Collateral |
AU-2 and AU-6 are assessed together as one check, so the 21 controls in this table make up the 20 checks each engine runs.
Each control is rated PASS, PARTIAL, FAIL, or N/A. N/A is used only when a check cannot apply, for example when a token in a SparkDex pool has no Flare FTSO price feed. When an engine cannot read something it needs from the chain, the control is rated PARTIAL with a note asking for manual review. It is never rated PASS.
Each pool, vault, or market then gets an overall rating from the count of its 20 results. It is FAIL if 3 or more controls are FAIL or fewer than 10 are PASS, PASS if 16 or more are PASS, and PARTIAL otherwise. An N/A counts as not passed.
Each of the 20 selected controls required adaptation from its traditional IT context to the DeFi smart contract domain. Each protocol is built differently, so each engine applies a control to the part of that protocol where it fits. Key adaptations include:
Full technical implementation details including RPC function selectors and code implementations are available upon request for institutional subscribers.
DeFi Sentinel Watch audits five protocols on Flare Network. The first three were SparkDex (20 pools: the top 10 V3 and top 10 V4 pools by TVL when the list was last reviewed), Spectra Finance (4 active yield tokenization pools: 2 stXRP markets and 2 sFLR markets), and Mystic Finance (3 lending vaults: FXRP, USDT0, and wFLR). The SparkDex pool list is reviewed quarterly (see 4.4). The Spectra list changes as pools mature: a matured pool is reported once and then retired. See sections 4.6, 4.7, and 4.8.
Two more protocols were added in November 2026: Kinetic Market (10 lending markets: 7 in the core pool and 3 in the FXRP isolated pool) and Firelight (the stXRP liquid staking vault). See sections 4.9 and 4.10.
Audits run on three days each week. SparkDex audits run every Sunday on 6 of the 20 pools (3 V4 and 3 V3). The rotation moves 3 places down each list every week, so each pool usually comes round every 3 to 4 weeks. The rotation follows the week number of the year, so one gap around the new year can be shorter or longer. Spectra Finance audits run every Tuesday on all 4 active pools, and Mystic Finance audits run every Thursday on all 3 vaults. PDF and Excel reports are generated automatically and delivered to the subscriber portal.
Kinetic Market audits also run every Tuesday (all 10 markets on every run), and Firelight audits run every Thursday (the stXRP vault on every run). For Spectra, Kinetic, Mystic, and Firelight, subscribers get an email when the week's report is ready.
Paid subscribers can open the full report archive and compare results across audit cycles to spot trends and configuration changes.
Our monitoring agent runs every 15 minutes. It checks this week's 6 SparkDex pools, the 4 active Spectra Finance pools, the 3 Mystic Finance vaults, all 10 Kinetic Market markets, and the Firelight stXRP vault.
For SparkDex it compares each pool's code hash (SI-7), fee tier (CM-6), and tick spacing (CM-6) with the values saved at that pool's last audit. The fee tier is compared only for pools with a fixed fee. V4 pools whose plugin sets the fee on every swap are compared on code hash and tick spacing. Any difference, or a pool with no saved values, starts a new 20-control audit of this week's 6 pools, and Continuous Monitoring subscribers get an alert once the new report is ready.
For Spectra it compares each pool's code hash with the previous check, and sends an alert when a pool comes within 14 days of maturity and again when it matures. For Mystic it compares each vault's code hash and owner with the previous check, and sends an alert when a vault's total assets fall 20% or more from one check to the next. A Spectra or Mystic alert goes to Continuous Monitoring subscribers. It does not start a new audit.
For Kinetic Market it watches each comptroller's admin, any proposed new admin, contract upgrades, the price oracle, and the pause guardian, and for each market: contract upgrades, paused deposits or borrowing, cash available for withdrawals falling 20% or more from its 24-hour high (markets holding over $10,000, at most one such alert per market per day), and markets more than 95% borrowed. For Firelight it watches contract upgrades, the address that can upgrade the vault, pauses, the FXRP the vault holds falling 20% or more from its 24-hour high (at most one such alert per day), and the value of each stXRP share dropping 0.5% or more from its high. The first reading of anything is saved as the starting point and never alerts, and a reading that fails is never treated as "no change". An alert goes to Continuous Monitoring subscribers and says what changed. It does not start a new audit.
Every quarter we conduct a full review of the top 10 liquidity pools by TVL for both SparkDex V3 and V4. If the rankings have changed a lot, we update the pool list and set new baselines for any pools we add. That keeps the audits on the highest-value pools.
Each engine saves a baseline for every pool, vault, or market on its first audit and replaces it at the end of every audit, so each audit compares against the one before it. A change is reported in the audit where it first appears. On a first audit there is nothing to compare against, so checks that look for change record a baseline and are rated PASS.
What it is: SparkDex is a decentralized exchange on Flare. Liquidity providers put two tokens into a pool and traders swap against it. SparkDex runs two releases side by side. V3.1 pools work like Uniswap V3: each pool has a fixed fee tier and tick spacing, and the factory owner can switch on a protocol share of swap fees. V4 pools run Algebra Integral v1.2.2: each pool has a plugin, a separate contract that runs on swaps and can set the fee, pool administrators who can change pool settings, and a SparkDex security registry that can restrict or halt a pool.
What we audit: 20 pools. The V4 list: stXRP-FXRP, FXRP-USDT0, USDT0-USDC.e, WFLR-USDT0, stFLR-WFLR, sFLR-WFLR, WFLR-FXRP, WETH-FXRP, WETH-USDT0, and stFLR-SPRK. The V3 list: USDT0-USDC.e, WFLR-SPRK, FXRP-USDT0, USDT0-CUSDX, sFLR-WFLR, WFLR-USDC.e, WETH-flrETH, WFLR-USDT0, WFLR-FXRP, and WETH-USDT0.
When: A weekly NIST 800-53 audit every Sunday, running all 20 controls against 6 pools: 3 from the V4 list and 3 from the V3 list (see 4.2 for the rotation). Between audits, our monitoring agent checks that week's 6 pools every 15 minutes (see 4.3).
In plain English: we check who controls the SparkDex factory and pool settings and whether their changes wait behind a timelock, whether the pool is the one SparkDex's factory lists for the pair, whether the pool price matches Flare's FTSO price, how much liquidity the pool holds, whether its code, plugin, or settings have changed, whether its code contains functions that could move funds, and how much of the pool depends on FAssets.
| Control | What the SparkDex engine checks |
|---|---|
| AC-2 | Who owns the factory that created the pool. The V3.1 owner can enable fee tiers and switch on the protocol's share of swap fees. The V4 owner can grant pool-administrator rights and change plugins and fee settings. A Safe multisig needing 2 or more signatures, or a timelock of at least 24 hours that is not run by a single wallet, is a PASS. A single wallet is a FAIL. An owner whose final controlling keys could not be identified is PARTIAL. |
| AC-3 | Owner, role, and upgrade events in the last 100,000 blocks (about 2 days) on the factory, and for V4 also on the plugin factory and its proxy admin. None is a PASS. Any is PARTIAL, to be checked against SparkDex announcements. |
| AC-6 | V4: who holds the pool administrator role. No administrators, or all of them controlled by a multisig or a timelock of at least 24 hours, is a PASS. A single-wallet administrator is a FAIL, because that key can install a new plugin. An administrator whose control could not be identified is PARTIAL. V3.1: searches the pool code for admin functions beyond fee settings (such as setPlugin, upgrade, withdraw, sweep, or rescue functions). None is a PASS. Any is PARTIAL. |
| AU-2/AU-6 | All events the pool emitted in the last 96,000 blocks (about 2 days). Any activity is a PASS. None is PARTIAL. |
| AU-9 | The pool's event history can be read back from the Flare blockchain, where it cannot be altered or deleted. |
| SC-5 | Liquidity depth. Reads both token balances and values them in US dollars with Flare FTSO prices (a token with no FTSO feed is priced from the pool when the other token has one). At least $25,000 in the pool with liquidity active at the current price is a PASS. Under $25,000, or no dollar price for either token, is PARTIAL. No liquidity active at the current price is a FAIL. |
| SC-8 | The documented SparkDex factory's record for the token pair (and, for V3.1, the fee tier) must point to this pool, so router swaps reach it. A match is a PASS. A different V4 address is PARTIAL, because the pool may be a custom one. A different V3.1 address is a FAIL. |
| SI-2 | The pool was created by SparkDex's current documented V3.1 or V4 factory, has a price set, and its reentrancy lock is open between transactions. If all three hold, it is a PASS. A pool from another factory is PARTIAL. No price set, or the lock engaged, is a FAIL. |
| SI-7 | SHA-256 hash of the pool code compared with the last audit. Any change is a FAIL, because pool code should never change. V4 also tracks the plugin address and the plugin's implementation. A replaced or upgraded plugin with unchanged pool code is PARTIAL. |
| IR-4 | Emergency stop. V4: the pool's status in SparkDex's security registry. Enabled is a PASS. Withdraw-only or disabled is PARTIAL, because an incident response is in effect. V3.1: whether the pool code has a pause function. One is a PASS. Without one SparkDex cannot halt the pool in an incident, which is PARTIAL. |
| CM-6 | V3.1: fee tier and tick spacing compared with the last audit. A change in either is a FAIL, because they cannot change in a V3 pool. A change in the protocol fee share is PARTIAL. V4: tick spacing, community fee, plugin, plugin settings, and community vault compared with the last audit. Any change is PARTIAL. The V4 swap fee is not compared when the plugin sets it on every swap. |
| RA-3 | The pool price compared with Flare FTSO prices for its two tokens. Within 2% is a PASS, more than 2% apart is PARTIAL, and more than 5% is a FAIL. An FTSO price more than an hour old is PARTIAL. FXRP is compared with the XRP/USD feed. If a token has no FTSO feed (stXRP, sFLR, stFLR, flrETH, SPRK), the control is N/A. |
| CP-9 | Exit window. Looks at the factory owner and, for V4, the authority that can upgrade the pool's plugin. All of them behind a timelock of at least 24 hours is a PASS. A multisig with no such timelock is PARTIAL, because its changes take effect at once. A single wallet with no such timelock is a FAIL. |
| SA-11 | Published audits for the pool's release. SparkDex publishes Protofire audits of its V3.0 DEX and the V3.1 upgrade, so a pool from the documented V3.1 factory is a PASS. Algebra's code has published audits, but none names SparkDex's deployed V4 contracts or the v1.2.2 core release, so V4 pools are PARTIAL. A pool from any other factory is PARTIAL. We read the audit listings; we did not match the audited code to the deployed bytecode. |
| SI-4 | Events in the last day (48,000 blocks) compared with the day before and with the one-day count at the last audit. No events in the last day, or in the last two days, is PARTIAL. At least 100 events and more than 3 times the larger of the other two counts is PARTIAL, as a possible attack or price dislocation. Otherwise it is a PASS. |
| IR-5 | Pause, upgrade, ownership, role, and pool-setting events on the pool, its factory, and for V4 its plugin and the plugin factory, since the pool's last audit, with a running total kept across audits. The first audit looks back 100,000 blocks, and later audits look back at most about 33 days. None is a PASS. Any is PARTIAL. |
| IA-3 | Both tokens must be the official contracts for the names in the pool's listing, checked against our list of verified token addresses (WFLR is also checked against Flare's contract registry). If both are verified, it is a PASS. A token not on the list is PARTIAL. A pool that holds different tokens from its name is a FAIL. |
| SC-7 | Dependencies compared with SparkDex's published addresses: the factory and both tokens, and for V4 the community vault, the plugin (it must be the one SparkDex's plugin factory created for this pool), and the plugin implementation. If all are verified, it is a PASS. A factory or community vault that does not match is a FAIL. A plugin that differs from the one the plugin factory created, a plugin implementation that is not the published one, or a token not on our list is PARTIAL. |
| RA-5 | Searches the pool bytecode for 9 function selectors that could move funds or replace the code: upgradeTo, upgradeToAndCall, two forms of withdraw, sweep, sweepToken, rescueTokens, recoverERC20, and emergencyWithdraw. Any found is a FAIL. A pool that is an upgradeable proxy is PARTIAL. For V4, a plugin upgrade since the last audit is PARTIAL when the plugin's upgrade authority has no 24-hour timelock. Otherwise it is a PASS. |
| CP-10 | FAssets dependency. States what each token depends on: FAssets, Flare staking, an issuer or bridge, or SparkDex's own token. A pool without FXRP or stXRP is a PASS. If FAssets tokens are more than 80% of the pool's value (in the stXRP-FXRP pool, if stXRP is more than 80%), it is PARTIAL, because LPs then carry mostly FAssets risk. |
What it is: Spectra splits an interest-bearing token (IBT) into a Principal Token (PT), which redeems for the underlying asset at maturity, and a Yield Token (YT), which collects the yield until then. Each Spectra market is a Curve-style pool that holds the IBT and the PT. PT contracts are upgraded through a shared beacon, and an OpenZeppelin AccessManager controls who may upgrade them. On Flare the IBTs are Firelight stXRP (underlying FXRP) and Spectra-wrapped Sceptre sFLR (underlying WFLR).
What we audit: 4 active pools: stXRP maturing November 26, 2026 and September 30, 2027, and sw-sFLR maturing March 15, 2027 and June 30, 2027. When a pool matures it is reported once, on the next audit, with the PT backing left for holders who have not redeemed, and then retired from the weekly audit. The August 2026 stXRP pool and the September 2026 sFLR pool have matured.
When: A weekly NIST 800-53 audit every Tuesday, running all 20 controls against every active pool. Between audits, our monitoring agent checks each active pool every 15 minutes for a code change and for maturity (see 4.3).
In plain English: we check who can upgrade the PT code and whether upgrades wait at least 24 hours, whether a PT still redeems for its full value and how the pool prices it, whether the PT contract holds what PT holders are owed, whether the pool has enough liquidity for PT holders to sell early, whether anything is paused, whether code or settings have changed, and how much depends on FAssets.
| Control | What the Spectra engine checks |
|---|---|
| AC-2 | Who can upgrade the PT code. The engine asks the PT's AccessManager whether known accounts can upgrade the PT beacon: accounts seen in role-grant events, the pool factory's admin, accounts found at earlier audits, and Spectra's DAO Safe address as published for Ethereum. Every upgrader a Safe multisig needing 2 or more signatures, or a contract whose upgrades wait at least 24 hours, is a PASS. A single wallet with no delay is a FAIL. If none of the accounts checked can upgrade, the upgrade authority is unidentified, which is PARTIAL. Anything in between is PARTIAL. |
| AC-3 | Role, permission, upgrade, and authority events on the AccessManager, the PT beacon, and the PT in the last 100,000 blocks (about 2 days). None is a PASS. Any is PARTIAL. |
| AC-6 | Who holds the AccessManager admin role, which can grant any permission. The same accounts and rules as AC-2 apply: multisig or delayed contract holders are a PASS, a single wallet with no delay is a FAIL, and an unidentified admin, or anything in between, is PARTIAL. |
| AU-2/AU-6 | All pool events in the last 96,000 blocks (about 2 days). Any is a PASS. None is PARTIAL. |
| AU-9 | The pool's event history can be read back from the Flare blockchain, where it cannot be altered or deleted. |
| SC-5 | Exit liquidity for PT holders. Values the pool's IBT and PT in the underlying asset. At least 10% of the value on the IBT side and, when a dollar price is available, at least $10,000 in the pool is a PASS. Less than 10% on the IBT side, or less than $10,000, is PARTIAL. An empty pool is a FAIL. |
| SC-8 | The PT's maturity on-chain must be within 2 days of the published maturity date, and its Yield Token contract must be deployed. If both hold, it is a PASS. A maturity more than 2 days off is a FAIL. A Yield Token that cannot be confirmed is PARTIAL. |
| SI-2 | Whether the PT is paused, and whether its IBT is paused where the IBT reports it. If neither is paused, it is a PASS. If either is paused, it is PARTIAL. |
| SI-7 | SHA-256 hash of the pool code, and the PT implementation the beacon points to, compared with the last audit. A pool code change is a FAIL. A PT implementation change alone is PARTIAL, to be checked against Spectra announcements. |
| IR-4 | LP token supply compared with the last audit. A fall of 50% or more is PARTIAL, because liquidity providers are leaving (within 30 days of maturity the report notes that some exit is normal). Otherwise it is a PASS. |
| CM-6 | Curve pool parameters compared with the last audit: gamma, mid fee, and out fee, or the off-peg fee multiplier, depending on the pool type. A and the fee are left out because they move by design in these pools. Any change is PARTIAL. |
| RA-3 | PT value. The PT rate (what one PT redeems for in the underlying) should stay at 1.0. Below 0.9999 is PARTIAL and below 0.99 is a FAIL, because the IBT has lost value and PT holders take the loss. The pool's PT price is then compared with the redemption value: more than 0.5% above it, or an implied fixed rate above 100% a year, is PARTIAL. |
| CP-9 | Upgrade delay. Every PT upgrader waiting at least 24 hours before an upgrade takes effect is a PASS. A single wallet with less delay is a FAIL. Any other upgrader with less delay is PARTIAL. An unidentified upgrade authority is PARTIAL. |
| SA-11 | Rated PARTIAL on every pool. Spectra's PT and YT code was audited by Code4rena (2024) and Pashov Audit Group (2024), but the Curve-style pool that holds LP funds is outside those audits, and we could not tie the Flare deployment to an audited commit. The report links Spectra's audit list. |
| SI-4 | Events in the last day (48,000 blocks) compared with the day before. At least 30 events and more than 3 times the day before is PARTIAL, as a possible incident or large rebalancing. No events in two days is PARTIAL. Otherwise it is a PASS. |
| IR-5 | Pause, upgrade, role, and authority events on the AccessManager, the PT beacon, and the PT, with a running total kept across audits. Each audit scans only the last 100,000 blocks (about 2 days). Any event found is PARTIAL. When the previous audit was longer ago than that, the blocks in between are not scanned, and the control is PARTIAL with the gap stated in the report. |
| IA-3 | The PT and its beacon must answer to the same AccessManager, and it must be the same one as at the last audit. Different AccessManagers, or a change since the last audit, is a FAIL. A beacon authority that cannot be read is PARTIAL. |
| SC-7 | Dependencies. The pool's two coins must be the expected IBT and this pool's PT, the PT's IBT and underlying must match, the IBT's underlying must be the expected asset (FXRP or WFLR), and the pool factory must be the same as at the last audit. Where no PT address is published, the PT seen at the first audit is used. Any mismatch is a FAIL. Anything unreadable is PARTIAL. |
| RA-5 | Upgrades and value loss. A PT implementation change since the last audit with no confirmed 24-hour delay is a FAIL, and with one it is PARTIAL. Any fall in the IBT share price is a FAIL, because it is a realized loss. A fall of more than 0.5% in the LP virtual price is PARTIAL. |
| CP-10 | Redemption backing and FAssets dependency. Compares what the PT contract holds with what PT holders are owed at maturity. 99.9% or more is a PASS, 98% or more is PARTIAL, and under 98% is a FAIL. For stXRP pools the report also states how much FXRP in the market depends on FAssets agent collateral. |
What it is: Mystic Finance is the app for Morpho lending on Flare. Its Core vaults are Morpho Vault V2 contracts (ERC-4626). You deposit one token, and the vault lends it out through adapters into Morpho Blue lending markets. Each vault has an owner who appoints roles, a curator who proposes changes to adapters, caps, fees, and gates, and timelocks that make the curator's changes wait before they take effect. Sentinels can cancel queued changes.
What we audit: 3 Core vaults: FXRP, USDT0, and wFLR.
When: A weekly NIST 800-53 audit every Thursday, running all 20 controls against all 3 vaults. Event checks cover every block since the vault's previous audit, up to about 17 days back (the first audit looks back 7 days). Between audits, our monitoring agent checks each vault every 15 minutes (see 4.3).
In plain English: we check who owns and curates each vault and how long the curator's changes must wait, how much of the vault could be withdrawn today, whether market oracles agree with Flare's FTSO prices, whether settings have changed or changes are queued, whether the value of a vault share has gone down, and how much is lent against FAssets collateral.
| Control | What the Mystic engine checks |
|---|---|
| AC-2 | The vault owner and curator. If each is a Safe multisig needing 2 or more signatures or a timelock of at least 24 hours not run by a single wallet, or the vault has no curator and the owner meets that test, it is a PASS. If either is a single wallet, the rating depends on the shortest timelock on the four fund-critical changes (adding an adapter and setting any of the three gates that can block deposits, transfers, or withdrawals): 24 hours or more is PARTIAL, because depositors get time to exit, and under 24 hours is a FAIL. Owners or curators whose control could not be fully identified are PARTIAL. |
| AC-3 | Owner, curator, sentinel, and allocator change events since the previous audit, and whether the owner or curator address differs from the last audit. No changes is a PASS. Any is PARTIAL. |
| AC-6 | The owner and the curator must be different accounts. Different accounts, or no curator, is a PASS. The same account is PARTIAL. |
| AU-2/AU-6 | Deposits, withdrawals, and interest updates since the previous audit. Any vault event is a PASS. None is PARTIAL. |
| AU-9 | The vault's event history can be read back from the Flare blockchain, where it cannot be altered or deleted. |
| SC-5 | What could be withdrawn now: idle funds in the vault plus what the vault could pull from each market (its supplied amount, up to the market's unborrowed cash), as a share of deposits. 15% or more is a PASS, 5% to 15% is PARTIAL, and under 5% is a FAIL. An exit gate set on the vault is PARTIAL. If no liquidity adapter is set, a PASS becomes PARTIAL, because normal withdrawals then use idle funds only. |
| SC-8 | Morpho's Vault V2 factory on Flare must confirm it created the vault, and the vault's asset must be the documented token. If both hold, it is a PASS. Otherwise it is a FAIL. |
| SI-2 | Every adapter must have been created by Morpho's current Market V1 Adapter V2 factory. If all of them were, it is a PASS. Any other adapter is PARTIAL, because it may be the older adapter Morpho replaced in December 2025 or custom code. |
| SI-7 | SHA-256 hash of the vault bytecode compared with the last audit. Any change is a FAIL, because Vault V2 code cannot be upgraded. The report also notes if the vault sits behind an upgradeable proxy. |
| IR-4 | Forced exits since the previous audit, where a depositor pulls money straight out of a market and pays a penalty because normal withdrawals are short of cash. Any is PARTIAL. Curator changes cancelled by the curator or a sentinel are reported and rated PASS, since they show the timelock review in use. |
| CM-6 | Fees, maximum rate, adapter registry, liquidity adapter, fee recipients, gates, adapters, markets, timelocks, abdicated functions, and caps compared with the last audit, plus any curator change queued in the timelock. Any change, or any queued change, is PARTIAL. |
| RA-3 | Each Morpho market's oracle price compared with Flare FTSO prices for its collateral and loan tokens. Within 2% is a PASS, more than 2% apart is PARTIAL, and more than 5% is a FAIL. Markets that cannot be compared, for example a token with no FTSO feed, are listed, and the control is then PARTIAL at best. |
| CP-9 | The shortest timelock on the four fund-critical changes. Under 1 hour is a FAIL. Under 24 hours is PARTIAL. 24 hours or more is a PASS when the curator is a multisig or timelock (or there is no curator), and PARTIAL when the curator is a single wallet or could not be identified. |
| SA-11 | Mystic's vault logic is Morpho's code, deployed from Morpho's factories, and we found no separate Mystic audit. If factory records confirm the vault is Morpho Vault V2 and every adapter is Market V1 Adapter V2, it is a PASS, citing Morpho's published audits (Spearbit, Zellic, ChainSecurity, Blackthorn, Certora, and others). Otherwise it is PARTIAL. |
| SI-4 | Net withdrawals since the previous audit as a share of deposits. 20% or more is PARTIAL. 50% or more is a FAIL, as a possible run on the vault. |
| IR-5 | Role, adapter, adapter registry, gate, timelock-cut, cancellation, and forced-exit events since the previous audit, with a running total kept across audits. None is a PASS. Any is PARTIAL. |
| IA-3 | Every market oracle must have been created by Morpho's oracle factory on Flare. If all of them were, it is a PASS. Any other oracle is PARTIAL and needs a manual review of its price source. |
| SC-7 | Dependencies. The vault asset must be the documented token, every adapter must point to Morpho Blue and belong to this vault, and every market must lend the vault's asset. A mismatch is a FAIL. A non-standard adapter registry, any gate set, an adapter not from Morpho's factory or registry, a market not using Morpho's AdaptiveCurveIrm rate model, or a collateral token not on our list is PARTIAL. |
| RA-5 | Value per share compared with the last audit. A drop larger than the management fee charged since then is a FAIL, as a sign of bad debt or an exploit. Any fund-critical change that can take effect with no delay is a FAIL. A vault behind an upgradeable proxy is PARTIAL. |
| CP-10 | FAssets dependency. In the FXRP vault all deposits depend on FAssets agent collateral, and the control states the amount and rates it PASS, since our FAssets agent monitors that system. In the USDT0 and wFLR vaults it measures how much is lent against FXRP or stXRP collateral. More than half of the vault is PARTIAL. |
What it is: Kinetic Market is a lending protocol on Flare, built as a fork of Compound. People supply tokens to earn interest, and others borrow against collateral. Each market is run by a "Comptroller" contract that sets the risk rules, uses a Flare FTSO-based price oracle, and has a pause guardian for emergencies.
What we audit: 10 markets. The core pool: kFLR, kSFLR, kWETH, kUSDC.e, kUSDT, kUSDT0, and kFLRETH. The FXRP isolated pool: isoFXRP, isoUSDT0, and isoSTXRP.
When: A weekly NIST 800-53 audit every Tuesday, running all 20 controls against every market. Between audits, our monitoring agent checks every market every 15 minutes (see 4.3).
In plain English: we check whether you could get your money out (how much of each market is lent out), whether the protocol keeps a reserve buffer against bad loans, whether the price feeds look right and stablecoins are holding their $1 peg, whether the value of a supplier's position has ever gone down, whether anything is paused, who controls the admin keys, and whether the contract code has changed since last week.
| Control | What the Kinetic engine checks |
|---|---|
| AC-2 | Who holds the protocol admin role. A Safe multisig needing 2 or more signers, or a timelock of at least 24 hours, is a PASS. A single key that can change risk settings or upgrade the market is a FAIL. An admin handover in progress is flagged. |
| AC-3 | Admin or code-implementation change events on the Comptroller and the market in the last 100,000 blocks. |
| AC-6 | Whether the emergency pause guardian is a separate account from the admin, so pausing and governance powers are split. |
| AU-2/AU-6 | Supply, withdraw, and borrow events in the last 50,000 blocks, to confirm market activity is being logged. |
| AU-9 | The market's event history can be read back from the Flare blockchain, where it cannot be altered or deleted. |
| SC-5 | Utilization (how much is lent out) and the cash left to withdraw. Up to 85% is a PASS, up to 95% is PARTIAL, above 95% is a FAIL. |
| SC-8 | The market is listed and active in its Comptroller. |
| SI-2 | Pause state: whether supplying or borrowing is paused. A market that is collateral-only by design is not flagged. |
| SI-7 | Implementation drift: whether the market or Comptroller code has been upgraded since the last audit. |
| IR-4 | Liquidations in the last 50,000 blocks. More than 25 is flagged as a sign of stress. |
| CM-6 | Risk parameters (collateral factor, reserve factor, interest-rate model) compared with the last audit. |
| RA-3 | Oracle prices. Stablecoins must be within 2% of $1. Other assets are flagged if the price moved more than 30% since the last audit, or if the oracle returns no price. |
| CP-9 | Protocol reserves compared with outstanding borrows. Reserves below 1% of borrows are flagged as a thin loss buffer. |
| SA-11 | Kinetic's public audit contest and bug bounty on HackenProof. |
| SI-4 | Borrow rate. Above 100% APR signals liquidity stress. |
| IR-5 | Pause and unpause actions on the Comptroller in the last 100,000 blocks, tracked cumulatively across audits. |
| IA-3 | The Comptroller uses Kinetic's documented FTSO oracle, and the oracle has not changed since the last audit. |
| SC-7 | The market accepts only the documented token contract for its asset. |
| RA-5 | Exchange-rate monotonicity: the supplier exchange rate should only ever go up. Any drop is a FAIL, because it means a loss from bad debt or an exploit. |
| CP-10 | FAssets dependency: the FXRP-backed value in the isoFXRP and isoSTXRP markets, flagged if that market's utilization is above 85%. |
What it is: Firelight is XRP liquid staking on Flare. You deposit FXRP (XRP bridged to Flare through FAssets) into the Firelight vault and receive stXRP in return. The vault is an ERC-4626 vault, sits behind an upgradeable proxy, has a deposit cap, and processes withdrawals in periods.
What we audit: the Firelight stXRP vault.
When: A weekly NIST 800-53 audit every Thursday, running all 20 controls. Between audits, our monitoring agent checks the vault every 15 minutes (see 4.3).
In plain English: we check whether every stXRP is still backed by at least 1 FXRP, how much of that FXRP the vault actually holds on-chain, how close the vault is to its deposit cap, whether withdrawal periods are still moving forward, who can upgrade the vault code, whether the value of stXRP has ever gone down, and how much of it depends on FAssets.
| Control | What the Firelight engine checks |
|---|---|
| AC-2 | Upgrade governance: who controls the vault's proxy admin. A Safe multisig needing 2 or more signers, or a timelock of at least 24 hours, is a PASS. A single key that could replace the vault code is a FAIL. |
| AC-3 | Role-granted, role-revoked, and ownership-transfer events on the vault and its proxy admin in the last 100,000 blocks. |
| AC-6 | Upgrade power sits in a dedicated proxy-admin contract rather than directly with a single wallet. |
| AU-2/AU-6 | Deposit and withdraw events in the last 50,000 blocks, to confirm staking activity is being logged. |
| AU-9 | The vault's event history can be read back from the Flare blockchain, where it cannot be altered or deleted. |
| SC-5 | Deposit cap headroom. At 95% of the cap or more, new deposits are about to be blocked, and this is flagged. |
| SC-8 | Vault contract code is deployed and answering at the documented address on Flare mainnet. |
| SI-2 | Whether the vault is paused. |
| SI-7 | Whether the vault code has been upgraded since the last audit. |
| IR-4 | Withdrawal periods are advancing. A schedule stalled for over a day is a FAIL, because queued withdrawals may not be claimable. |
| CM-6 | The deposit cap compared with the last audit. |
| RA-3 | Backing ratio: FXRP held for stakers per stXRP. Below 1.0 is a FAIL (under-backed). |
| CP-9 | On-chain FXRP coverage: how much of what stakers are owed the vault holds directly. 98% or more is a PASS; below 50% is a FAIL. |
| SA-11 | The audits (OpenZeppelin and Coinspect, 2025) and the Immunefi bug bounty listed in Firelight's integration docs. |
| SI-4 | Outflow surges: more than 20 withdrawals and more than three times as many withdrawals as deposits in the last 50,000 blocks. |
| IR-5 | Pause, unpause, upgrade, and admin-change events in the last 100,000 blocks, tracked cumulatively across audits. |
| IA-3 | The vault's upgrade admin is the same contract as at the last audit. Any change is a FAIL, so it can be checked against a planned governance action. |
| SC-7 | The vault accepts only the official FAssets FXRP token. |
| RA-5 | Share-value monotonicity: the FXRP value of one stXRP should never go down. Any drop is a FAIL (slashing, cover payout, or exploit). |
| CP-10 | FAssets dependency: all FXRP in the vault depends on FAssets agent collateral. Flagged if more than half of stXRP is re-used as collateral on Kinetic Market. |
This summarizes our review of all 20 NIST SP 800-53 Rev. 5 control families, about 310 primary controls.
| Family | Controls | Included | Reason for Exclusions |
|---|---|---|---|
| AC: Access Control | 17 | 3 included | Session, device, and wireless controls have no smart contract equivalent |
| AT: Awareness & Training | 5 | 0 included | Organizational human behavior; no on-chain equivalent |
| AU: Audit & Accountability | 16 | 3 included | Blockchain immutability handles retention; session audit N/A |
| CA: Assessment & Monitoring | 9 | 0 formal | CA-7 incorporated into AU-6/SI-7; no formal ATO equivalent |
| CM: Configuration Mgmt | 19 | 1 included | Procurement and development lifecycle controls N/A for deployed contracts |
| CP: Contingency Planning | 13 | 2 included | Organizational plans and physical site controls N/A; blockchain is distributed. CP-9 and CP-10 adapted to exit windows, reserves, backing, and FAssets dependency |
| IA: Identification & Auth | 12 | 1 included | No sessions or logins in smart contracts; wallet addresses assessed in AC-2. IA-3 adapted to check the identity of the tokens, oracles, and authorities a pool or vault relies on |
| IR: Incident Response | 10 | 2 included | Organizational training and planning N/A; incident handling and incident history assessed in IR-4 and IR-5 |
| MA: Maintenance | 6 | 0 included | Physical maintenance N/A; code upgrades tracked in SI-7 |
| MP: Media Protection | 8 | 0 included | Physical media N/A; blockchain data is public and immutable |
| PE: Physical & Environmental | 20 | 0 included | No physical location; blockchain is globally distributed |
| PL: Planning | 12 | 0 included | Organizational planning documents; no on-chain equivalent |
| PM: Program Management | 32 | 0 included | Organizational governance, outside the scope of on-chain assessment |
| PS: Personnel Security | 9 | 0 included | Permissionless DeFi has no formal personnel structure; teams are often pseudonymous |
| PT: PII Processing | 8 | 0 included | DeFi protocols do not collect PII by design |
| RA: Risk Assessment | 10 | 2 included | Price and value checks in RA-3 and on-chain vulnerability indicators in RA-5; formal risk categorization is organizational |
| SA: System & Services Acq. | 23 | 1 included | Procurement and development lifecycle N/A for deployed contracts |
| SC: System & Comm. Protection | 51 | 3 included | Network architecture controls (firewalls, VPNs, wireless) N/A to permissionless blockchain |
| SI: System & Info. Integrity | 23 | 3 included | Malware, spam, session controls N/A; core integrity controls implemented |
| SR: Supply Chain Risk Mgmt | 12 | 0 formal | Partially incorporated into SI-7; full supply chain analysis is future capability |
Controls we plan to add as the tooling matures:
Weekly audits applying these 20 controls to Firelight, Kinetic Market, SparkDex, Spectra Finance, and Mystic Finance on Flare Network. Free subscribers get 5 core controls every week. No credit card required.
Subscribe free →