This pool lends real money to agents with no collateral. A bug here costs lenders their deposits, so a report is welcome even if you are not sure it is exploitable.

Use GitHub's private vulnerability reporting — the Report a vulnerability button under this repo's Security tab. It is private, it timestamps your report, and it keeps the thread in one place.

You can also write to contact@priors.trade; say in the subject that it is a security report.

If neither is available to you, open a public issue that says only that you have something and asks for a channel. Do not put details in a public issue. We will answer with somewhere private to send them.

You do not need to write a report before you hear from us. But the more of this you can say up front, the faster it moves — and none of it requires exposing an exploit:

• Which function, in which contract, at which address or commit.
• What an attacker gets: whose money, how much, under what preconditions.
• A test or a trace. This repo is Foundry — a failing forge test against src/ is the clearest thing you can send. A fork PoC is just as good.
• Whether it applies to the live deployment or only to an older one.

If you would rather not share specifics before agreeing terms, we understand — but please at least name the affected function and your own severity assessment. We cannot evaluate, prioritise, or credit "a few real issues" with no category attached.

• An acknowledgement within 3 working days.
• An assessment — confirmed, not reproducible, or out of scope, with reasoning — within 14 days.
• Credit in the fix commit and release notes, under whatever name or handle you choose, unless you ask us not to.
• We will tell you plainly if we think you are wrong, and why. We would rather argue than go quiet.

In scope

Out of scope

• The v1 contracts (CreditPool, TreasurySponsor v2/v3, ReserveFunder), including the v1 pool at 0x0259889e6EBab1a18CeE7e62Bc5B9648FB6C44e5, paused since the v2 cutover, and the older pools before it. They are kept in this repo and in the README as history. Findings against them are interesting only where they also apply to v2 — say so explicitly if they do.
• USDG (0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168), the $PRIORS token (0xeDBf91223639800BCd5756815CAf908Df3b890bE) and the ERC-8004 identity registry at 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432. Not ours; how our contracts handle them is in scope.
• The Robinhood stock tokens, their issuer's powers (pause, block, burn, upgrade) and Chainlink's price feeds. Not ours; how the stock vault copes with them is in scope.
• Third-party RPC endpoints. Their rate limits and archive policies are their business; how this SDK copes with them is ours, and that part is in scope.
• Anything requiring a compromised owner key, a malicious chain reorg beyond finality, or control of the Safe. Key handling itself is in scope; assuming the keys are already stolen is not.
• Gas optimisation, style, and "best practice" with no exploit path. Send those as ordinary issues.

So nobody spends time on ground that is already covered, and so a rediscovery is not mistaken for a new finding:

v2: docs/SECURITY-v2.md lists every finding from the pre- and post-launch reviews of the v2 set, with its severity, its fix or its accepted residual, and the test that shows it. In short: the self-backing yield loop (N-1) is fixed by the fee lock, with one residual path around it (SO-1, holding stake only while marking a default; yield only); the utilization freeze (N-2) by a 100% cap; the farmable keeper bounty (F-1) is mitigated by setting it to 0; the seat vault's stale offers (X-1) and idle seats (X-2) are fixed; the self-seat loop (X-3) is gated by repaid history and closed economically by the seat's market value; the treasury's invite-to-raise path (T10) is bounded by its epoch cap. The growth seat vault's two internal reviews (protocol-seat farming H-1, eligibility bound to the owner the Safe vetted R2-1, and the rest) were fixed before it was deployed. None of these reaches lender principal.

v1 (now paused; kept for the record):

• A defaulting root sponsor's earned credit was not retired, letting backing be counted twice and leaving lenders exposed. Fixed in the live pool. The proof-of-concept is committed as a permanent regression guard in test/ReviewPoC_RootEarnedDoubleSpend.t.sol, so you can read exactly what it was and confirm it is closed.
• A parameter-only mitigation for that same issue is documented and tested in test/BetaMitigationMinStake.t.sol: raising minStake beyond an attacker's budget closes the only door into rootness without a redeploy. It is kept because it is the lever available in a hurry.
• A dead root sponsor's stake was not charged for a defaulted child, so the first-loss reserve paid instead and lender principal was destroyed. markDefault left the sponsor liable for nothing once it was already defaulted itself. Fixed: liability is now !s.defaulted || (s.isRoot && s.stake > 0). Pinned by test_aDeadRootsEarmarkedStakeIsSlashedForItsChild and test_withAnEmptyReserveTheDeadRootsStakeStillProtectsLenders in test/SponsorLiability.t.sol.
• The same defect had a second door, in vouch. A dead sponsor's child could be taken over with a dust vouch, and the takeover branch zeroed delegatedIn while the child's loan was still drawn — collapsing a stake-backed claim to dust just before the default, which is strictly worse than the first path. Fixed with a principalOut == 0 gate on takeover; an orphan with a live loan now waits for that loan to close. Pinned by test_aTakeoverCannotVoidBackingForADrawnLoan, and by invariant_exposureWithinCapacity, which is what caught it at depth 400 after the first fix looked complete.
• A sponsor could withdraw delegation that was underwriting a live loan. unvouch is now bounded by delegatedIn - principalOut. Pinned by test_unvouchCannotReleaseDelegationBackingALiveLoan.
• A defaulted root's residual stake was stranded forever, because _capacity returns 0 for a defaulted agent and withdrawStake measured against it. A settled defaulted agent that owes nothing and backs nothing can now recover it. Pinned by test_aSettledDefaultedRootCanRecoverItsResidualStake and its negative case.

All four were live on v1 as of the 2026-09-21 cutover. Because these contracts are not upgradeable, "fixed in src/" and "fixed on chain" are different claims with a migration between them, and for about ten hours they were not the same thing here — see Credits. scripts/verify-migration.mjs checks the deployed v1 runtime bytecode against the compiled artifact, so you can confirm which one you are looking at rather than trusting this file. It does not read the v2 record: for v2, compare each address in deployments/4663.v2.json against forge build output the same way (immutables and the PoolV2Lib link zeroed, metadata stripped). The v2 set matched on 2026-09-25; seatVaultV4 and seatSizerV4 matched on 2026-09-29, and so did V3's seatSizer. For the stock vault the record holds the proxy (StockVaultProxy): what matches forge build of src/StockVault.sol is the implementation behind it (its ERC-1967 implementation slot): 0x9E80C9839d1331C945BB7Bd7DB5cE4a07124d1a6 since the upgrade of 2026-10-23 (SV-20, a new price tape begins at the first round of the last 20 days on a feed that drops its oldest rounds too), whose code matches the build, and so does the code of its StockVaultHolds (0x8f3750Bbe3d9548f95c56a1e75764eb4343Ec046, the vault's holds()), byte for byte (checked 2026-10-23; before it, 0xd30396A79D6b5BDB86D09B8c7907aD2820a42c72 from the upgrade of 2026-10-18 (SV-19, a tape behind no longer seizes a default's whole deposit), whose code and its StockVaultHolds' (0x51bd4AF40B0b241C90ADf0210A80004BaeC05f2B) matched the build (checked 2026-10-18 and 2026-10-23); 0xcD1A85940A6A10C8f47853165A516d397f14BAa9 from the upgrade of 2026-10-17 (SV-18, the price tape), whose code and its StockVaultHolds' (0xa09C616Ffaa94Eb364051475Bba10E82Cc2Bb593) matched the build (checked 2026-10-17); 0x02f0bF6259bDFef1Dad13D63b6D684c98596af5d from the upgrade of 2026-10-13 (the fair default, SV-11), which matched the build (checked 2026-10-16); 0x796FCcBdab6d473Ab22728D246AcAea0905b8E0B from the upgrade of 2026-10-11 (SV-17), which matched the build the day it was deployed; 0x737b015244C2115E774FABda72325C719b997d7C from the upgrade of 2026-10-10, deployed on 2026-10-08; 0xAe8f0A34A0bEf514D61132726bCF6a78960672a4 from the upgrade of 2026-10-10; 0xC16f7230b79Fb7dB3b1761A23e9d56365300B2A4 from the upgrade of 2026-10-04, which matched on 2026-10-07; 0x32F1c32A8bdDCd72B18A4f97dc815F50099ad0A5 from the upgrade of 2026-10-01, matched that day; 0x8Be04c08De0158c88F84875DAe181054c30734fA matched on 2026-09-30 and the first one, 0xF781b2634254d7819E9E17BfFc9D18C54C32008b, on 2026-09-29). The six protocol contracts (poolSteward, revenueRouter, buyAndBack, priorsLiquidity, swapLimiter, keeperHelper in the record) matched forge build of src/ on 2026-10-07, immutables masked and the metadata hash included. seatVaultV5 and its nine linked libraries (their addresses in the README's table) matched forge build of src/ on 2026-10-09, with the library links filled in, immutables and each library's own address masked, and the metadata hash included.

An independent rediscovery of a fixed issue is still worth telling us about, and we will say so and credit the work. It is not a new finding.

People who have found something real, or told us something we needed to hear.

• llen (@yossweh) — GHSA-4j38-23rc-qmv9, 2026-09-20. Reported that the dead-root accounting defect and its vouch takeover variant were still present in the deployed bytecode, with two proof-of-concepts executed against the live contract and the live USDG at a fork anchor. We had found and fixed both in src/ about an hour earlier — the advisory cites our own d2f0019 and fb1a0e5 as the patched versions — so this was not a new defect. It was something more useful and easier to miss: a published fix is not a deployed fix, and for ten hours the live pool ran pre-fix code with real deposits behind it while the repository looked patched. The report is the reason the cutover was not left to drift. Also correctly flagged that deposit reverts ZeroAmount for an amount smaller than one share once the share price passes 1:1 (see below), and proposed a stronger invariant than the two we had: assert that a defaulted root's stake is either charged or explicitly released, never left where withdrawStake reverts forever.
• The private reports of 2026-09-23 to 2026-09-29: 38 GitHub advisories and one email, each answered, and listed by row in docs/SECURITY-v2.md ("Private reports"). First reports: @sands786 (P-10, O-1), @sebattoriq (F4), @andelaiceee-code (F5), @Fdxyz (F6), @brianyazzz (F7, O-3), @xShadowxIQ (P-11), @johndastech-glitch (P-12, C-1), @0ex-NightFall (P-13), @xbyteid (C-2), @mmasyoga0 (FAC-1), @daffhaidar (IB-2), @Muhamadluis (O-2) and @Firlinata (S-1); Gerald Gerald reported P-12 by email the same day. Later reports of the same causes: @islaintent, @Godswork4, @dimazz12, @clementnaomi064-spec, @Sangmadun, @JasmeJun, @ginan15, @ashraf9191 and @rabbinik.
• The reports of 2026-09-29 and 2026-09-30: @Zhhns12 (SV-13) and @byfor8 (SV-14, and SV-13 the same night) on the stock vault: a deposit made after an issuer burn paid the earlier positions, and a line could be drawn past the loan-to-value of what was left, fixed by an upgrade before any stock was deposited. @byfor8 (P-14, also @fandiyana) and @sebattoriq (P-15) on pay_url's guard, fixed in 0.2.3.

Not fixed, deliberately: the ZeroAmount revert on a sub-share deposit. convertToShares rounds down, in the pool's favour, which is the correct direction for an ERC-4626-style vault; the effect is that the smallest depositable amount becomes one share's worth rather than one unit. It cannot be aimed at a third party and it costs nothing but a retry, so it stays. Reported for completeness and recorded here so it is not re-reported as new.

There is a bounty programme now: BOUNTY.md. It says what each severity is worth, which addresses are in scope, and what is explicitly not.

This page used to say there was no programme and nothing was promised. That was the honest position while nothing was funded; it is no longer the position. Two things carried over from it unchanged, because they were right: the ceiling is small and stated in public rather than implied, and a report still gets a straight answer, a fix, and public credit whether or not it pays. Do not make disclosure conditional on a figure we have not agreed to — we will decline, and fix it anyway.

The live v2 pool holds real deposits. Reproduce against a local Anvil fork or a testnet deployment, never against mainnet:

anvil --fork-url https://rpc.mainnet.chain.robinhood.com

We will not pursue anyone for good-faith research that stays within this scope, tests on a fork, avoids touching other people's funds or data, and gives us a reasonable chance to fix things before going public. Draining the live pool to prove a point is not good-faith research.

Our own contracts are not upgradeable, except the stock vault. No proxy, no initialiser, no admin hatch in anything under src/ but StockVault (since 2026-09-28), which sits behind a Transparent proxy (StockVaultProxy) whose ProxyAdmin the timelock owns since 2026-10-07 (the 2-of-3 Safe did before): a bug there can be fixed by an upgrade the Safe schedules on the timelock, which runs 48 hours later at the earliest until 2026-10-11 19:49 UTC and, from then, the moment the Safe sends it (the timelock has no delay from then, below). An upgrade could also move what the vault holds (docs/SECURITY-v2.md, "StockVault"). Everywhere else, fixing a real bug means deploying a new pool and migrating state, which has been done more than once (on v1, then from v1 to v2) and is not cheap — so a confirmed finding may take longer to close than a proxy-based protocol would need. The delay is the architecture, not us ignoring you.

The identity registry we depend on is a different story, and an earlier version of this file was misleading about it. 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 is not ours and it is not immutable: 130 bytes of code, an EIP-1967 implementation pointer, an empty admin slot — a UUPS proxy — and owner() is 0x547289319C3e6aedB179C0b8e8aF0B5ACd062603, an address with no code at all. A single ordinary key can change what that registry says about who owns which agent, and this pool believes the registry completely. Whoever holds it could withdraw every root's stake, draw every open credit line, and claim every unclaimed sponsor fee. On v2 that is still true of roots' stake and open lines, while lenders' deposits stay whole (test_X5_registryUpgradeAdminTakesEveryRootStake).

Findings in that registry are out of scope because we cannot fix them. Findings about how this pool trusts it are very much in scope, and we would rather hear them.

The levers we do hold, and how fast they move:

• Fast: the pool's guardian (the 2-of-3 Safe) can pause new risk for at most 14 days at a time; exits never pause. The Safe owns treasury v4 (setRules, setInviter, freeze, retire) directly, and each seat vault, V3 and the growth vault V4, through the SeatSizer that owns it (execute: setParams, setGates, pauseSeats, freezeSeat, retire), so those need two signatures and no delay. The same goes for the stock vault's settings (setAsset, setParams, pause, freezePosition, writeOff, retire), but not its code: its ProxyAdmin (upgradeAndCall) is the timelock's since 2026-10-07, which has no delay either from 2026-10-11 19:49 UTC (next point). Treasury v4 caps new lines at $100 a week (rules().epochCap) and is topped up by hand by the Safe; the token's creator fees are not routed to it.
• Through the timelock, slow until 2026-10-11 19:49 UTC, then not: the pool's owner is the PoolSteward (since 2026-10-06), which only the TimelockController can call (the Safe proposes and executes, no admin). Until 2026-10-11 19:49 UTC the timelock's delay is 48 hours: setParams, withdrawReserve and the other owner calls are visible on chain for two days before they can run, and operations already scheduled keep their ready times. On 2026-10-09 the owner decided to drop the delay: the Safe scheduled updateDelay(0) on the timelock (tx 0x2095a36a5c0897dac7e21c780216318386fed8d8bbea35aad80b29eeb369bf1b, block 84,415,642), executable from 2026-10-11 19:49:05 UTC. From then the Safe can schedule and execute in the same block: every operation is still public on chain (CallScheduled, CallExecuted), but there is no window to react before it runs. Whatever the delay, the steward refuses a fee split or a reserve withdrawal outside its fixed policy. That policy is not a lock: the Safe can leave it through a public handback (transferOwnership back to the timelock), 48 hours after it is scheduled until 2026-10-11 19:49 UTC and in one block from then (docs/SECURITY-v2.md, X1). No owner call reaches lender deposits or a backer's locked shares. The same timelock, on the same delay, gates a stock vault upgrade, the one-time setters of BuyAndBack and the SwapLimiter, and SeatVaultV5's settings.
• Rule-bound, no timelock: once a day anyone can call PoolSteward.sweep(). It sends the reserve above its target (the larger of 190 USDG and 10% of principal out; at or under the target, half of what arrived since the last sweep) to the RevenueRouter, never below the hard floor (the larger of 190 USDG and 2% of principal out) and nothing under 25 USDG. The destination is fixed; the Safe, as guardian, can pause the sweep. A sweep that moves more than that rule, or anywhere else, is a finding.

Expect a pause first and a migration later.