RWA Sonar
← All protocol dossiers

Source fetched 2026-09-26T00:55:53Z

SECZ × Loopscale

Configuration was decoded for this exact token Evidence for this stage was checked 2026-09-23T18:25:08Z. The protocol or product source names this exact token. Configuration decoding is not execution proof.

Source-described use: Posted as collateral in 1 Loopscale loan, read on-chain; open principal against it: $1,514 in stablecoins. 1 lending vault lists it as collateral.

Open SECZ token report · Open securitize issuer dossier

Exact token and source-described action

Solana token address
5VzwKkvynPJzcgwhBe7ESEyNgqMbo15yBu7Sehssd9ED
Actions described by source
collateral, borrow
Source-reported integration status
live
Access limits
Observed loans, not a published collateral listing. Loopscale and issuer eligibility, allowlisting and transfer restrictions apply to any new loan or liquidation transfer.
Direct links
Open market / product ↗ · Protocol documentation ↗

Proof status: a source listing does not prove execution

Achieved proof stage
decoded
Source proof status
exact-token-registry
Source fetched
2026-09-26T00:55:53Z
Activity observed
An activity indicator was observed at 2026-09-23T18:25:08Z; its stated basis is positions, debtAgainstCollateralUsd. Reported metrics are not independently executed trades.
Account existence
checked (2/2 referenced accounts)
Configuration decoded
Performed — Loan account collateral and ledger records, plus the MarketInformation asset entry (oracle, maximum price age, LTV, liquidation threshold, allocation cap) and the lender strategy terms each loan is checked against. Decoded at slot 450520007 with the published IDL ↗.
Read-only execution simulation
Not performed

Source evidence

Referenced accounts and owners

RoleAddressExistence checkExpected ownerObserved program owner
borrow-vaultHb681PyyDgUmixkX2UVhDFnzHe3DSwvLTxQkRGbuP33KexistsNot established1oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF78
loan-accountHUyo5aYaNQvodYmy8TmjnpcxQCk3PVsbyTJUyjmAihFxexists1oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF781oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF78

The source data records observed owners. Where the source publishes no expected owner, the expected owner is not established. Account existence and owner confirm the published reference; they do not decode configuration or prove that a user action can succeed.

Recorded parameters

Maximum LTV
20%
Liquidation LTV
40%
Liquidation penalty
Not reported
Configured / observed size
Not reported
24 h volume
Not reported
24 h transactions
Not reported
Oracle
Not reported

Markets and configured addresses

Decoded market route

Configuration decoded · 2026-09-23T18:25:08Z

SECZ collateral → USDC debt · Loopscale “USDC RWA” vault

This is one collateral-to-debt route. Other markets for the token are not included.

Market
DTzzuGFVZN8nmCS9HZubnM4vogqR8c4Rs5mChpLVjuCb
Collateral reserve
Not applicable (order book): SECZ is asset index 1 of MarketInformation DTzzuGFVZN8nmCS9HZubnM4vogqR8c4Rs5mChpLVjuCb
Debt reserve
Not applicable (order book): lender strategy 3dwhqaSbEmuXnjVV21yrVSMNeACpsWdh1BGCk18oWWR5
Debt asset
USDC · EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
Reserve status
active (SDK code Not performed / not established)
Expected programme owner
1oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF78
Observed programme owner
1oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF78 · matches official mainnet programme ID
Maximum LTV
20%
Liquidation threshold
40%
Liquidation bonus range
Not established
Collateral deposit cap
Not established SECZ
Debt borrow cap
Not established USDC
Oracle
Loopscale BEAM adapter, upstream RedStone end-of-day feed “SECZ_EOD” feed E22Z2nKBdA3RpJhM8G2mB35zFA95Qdbs3WGbMNxFhmuH · price chain BEAM account E22Z2nKBdA3RpJhM8G2mB35zFA95Qdbs3WGbMNxFhmuH (oracle type code 19) → RedStone feed account DjDd8qqL2FPFsiQyshnVL7SkSE9crq2xee4amBQmQbRB (SECZ_EOD) · TWAP chain Not performed / not established · maximum age 65535s
On-chain observation
confirmed slot 449783798 · reserve last updated at slot Not performed / not established
Decoder
stocks/lib/loopscale.mjs (decodeLoan, decodeMarketInformation, decodeStrategy, decodeVault, decodeProtocolAdminState) against the program's on-chain Anchor IDL 8jaPDEbzjkgJT8qTgMwCxbVUZt3p2MoMsCovyNyuNShD; fixture stocks/fixtures/loopscale-market-secz.sample.json
Read-only execution simulation
not-performed — Opening or liquidating a SECZ loan needs a funded, Securitize-whitelisted wallet and Loopscale's protocol-admin co-signature; a simulation without them would not test a real holder route.

Documentation vs chain

  • 23 Sep 2026 · info Docs say program upgrades need a 3-of-5 multisig; the chain shows 4 of 7 voters and a 24-hour time lockThe chain is stricter than the docs (a higher threshold and a 24-hour delay the docs do not mention), so this is not a weaker control than advertised and no single party can upgrade either way. It matters because the docs are the only published description of who can change the code that holds SECZ collateral, and they are out of date: a lender cannot rely on the page to know the current threshold, voter set or delay.

    info · Docs say program upgrades need a 3-of-5 multisig; the chain shows 4 of 7 voters and a 24-hour time lock (observed 2026-09-23)

    Scope: protocol governance documentation out of date

    Published claim

    Loopscale's curator security page says program upgrades need a 3-of-5 multisig, in three places: "All program upgrades require approval from a 3/5 multisig. This governance model ensures no single party can deploy changes unilaterally."; "3/5 multisig governance for contract upgrades (via Squads)."; and the address table row "Multisig Authority DwBXwJDZ4Av4miT62sEssWJUinkzwkmPPB4Fg3fKEfft 3-of-5 governance authority". No time lock is mentioned.

    Observed reality

    The core program 1oopBoJG58DgkUVKkEzKgyG9dvRmpgeEm1AVjoHkF78 (programData 8KbXd8ATqDQQTozYv2TsCzHUDoiRyWe4DmzHdmJLgdNj, last deployed at slot 440130674, 2026-08-18T20:54:52Z) has upgrade authority DwBXwJDZ4Av4miT62sEssWJUinkzwkmPPB4Fg3fKEfft, which is vault index 0 of Squads v4 multisig C4awuufiuL8DNT5wMDP27HneKKqbgynrsbCa4XYGSuPk. That multisig has 9 members: 6 with initiate+vote+execute, 1 vote-only (stnD32KEQkgA7LTVNprUPBWXt86fstt1sdUiwUUJH4j) and 2 initiate-only (CyNKPfqsSLAejjZtEeNG3pR4SkPhSPHXdGhuNTyudrNs, FmoQf6t1fxNhvzJ7iVyoiue5C8JuhkLxpp6it9jAkkua). So threshold 4 of 7 eligible voters, time lock 86,400 s, config authority none (changes go through the multisig itself). Finalized reads at slot 449798739–449798741.

    • Loopscale programData account (upgrade authority) ↗ · rpc:getAccountInfo 8KbXd8ATqDQQTozYv2TsCzHUDoiRyWe4DmzHdmJLgdNj bytes 0-45 (UpgradeableLoaderState::ProgramData), slot 449798739 · checked 2026-09-23T19:31:59Z
    • Squads v4 multisig account ↗ · rpc:getAccountInfo C4awuufiuL8DNT5wMDP27HneKKqbgynrsbCa4XYGSuPk decoded with stocks/lib/squads.mjs decodeSquadsMultisig (threshold 4, timeLock 86400, 9 members), slot 449798741; squadsVaultPda(C4awuu…, 0) = DwBXwJ… · checked 2026-09-23T19:31:59Z

    Why it matters: The chain is stricter than the docs (a higher threshold and a 24-hour delay the docs do not mention), so this is not a weaker control than advertised and no single party can upgrade either way. It matters because the docs are the only published description of who can change the code that holds SECZ collateral, and they are out of date: a lender cannot rely on the page to know the current threshold, voter set or delay.

    What resolves it: Resolved when Loopscale's security page states the on-chain threshold, voter count and time lock of Squads multisig C4awuufiuL8DNT5wMDP27HneKKqbgynrsbCa4XYGSuPk, or the multisig is reconfigured to 3 of 5.

  • 23 Sep 2026 · caution Docs call CyNKPf… a co-signer that "cannot initiate actions on its own"; on-chain it is the protocol admin and signs refinances aloneThe key is an operating admin, not only a supplemental co-signer: it rolls loans on its own and co-signs every change path. What a refinance signed by it alone can change for a lender (rate, term or collateral terms beyond the strategy's own limits) was not established; the point is that the published description of the key understates its role, so its custody (an AWS-based signer, per the docs) is part of the lender's risk.

    caution · Docs call CyNKPf… a co-signer that "cannot initiate actions on its own"; on-chain it is the protocol admin and signs refinances alone (observed 2026-09-23)

    Scope: protocol key role narrower in docs than on-chain

    Published claim

    "In addition to multisig approval, all program transactions currently require a co-sign from the Loopscale Secrets Manager — a read-only AWS-based signer. This key cannot initiate actions on its own and functions only as a supplemental safeguard to ensure transactions are constructed as intended." The address table lists CyNKPfqsSLAejjZtEeNG3pR4SkPhSPHXdGhuNTyudrNs as "Secrets Manager Signer — Supplemental co-sign, AWS-based key".

    Observed reality

    The same key is protocol_admin and refinance_admin in ProtocolAdminState HcgXEnEsgvGowVnSjMmrzSewdx9yGvfXixiuMJPhyW2z (this entry's governance block), the signer the IDL requires for create_timelock/execute_timelock on vault market changes, and an initiate-only member of the upgrade multisig (it can propose upgrades). The latest refinance of the SECZ loan, tx 3JGFRfzWr7zwjFZRitv4RX8fRmQubbLM3DH7RBouzuUyse9hyv9qkC71o3ZxTkm9rX6T6GjLtBgL6eYs4VCKLjp7 (RefinanceLedger, 2026-09-23T18:00:58Z), has that key as its only signer and fee payer.

    Why it matters: The key is an operating admin, not only a supplemental co-signer: it rolls loans on its own and co-signs every change path. What a refinance signed by it alone can change for a lender (rate, term or collateral terms beyond the strategy's own limits) was not established; the point is that the published description of the key understates its role, so its custody (an AWS-based signer, per the docs) is part of the lender's risk.

    What resolves it: Resolved when Loopscale documents CyNKPfqsSLAejjZtEeNG3pR4SkPhSPHXdGhuNTyudrNs as protocol admin / refinance admin and says which actions it can take alone, or when those roles move to a different key.

What a lender's exit depends on

  • 23 Sep 2026 · Issuer action requiredA lender cannot count on liquidation timing: the loan's 40 % liquidation LTV triggers on Loopscale, but realising the collateral waits on an off-chain issuer onboarding decision. Securitize could also freeze the loan's own collateral account, since the freeze authority stays with it.

    Liquidating the SECZ collateral needs Securitize to act first. Every new SECZ token account is created frozen (Token-2022 DefaultAccountState = frozen on mint 5VzwKkvynPJzcgwhBe7ESEyNgqMbo15yBu7Sehssd9ED), and a frozen account cannot receive tokens. Loopscale's documented liquidation engine mkr7azob5ee3RC64BVoHQPu7FnyaXzJnLMN8jm942pQ holds no SECZ account, and of the 123 SECZ token accounts (90 initialized, 33 frozen) the only one owned by a Loopscale account is the loan's own collateral account. So the seized SECZ can go nowhere until Securitize thaws a receiving account (the liquidator's, the lender vault's or a buyer's) — in both observed thaws Securitize did this in the same transaction that registered the wallet in its DS registry (memos DSRegistryServiceInvestorAdded / WalletAdded). Securitize, through the program behind the freeze authority, controls both whether that thaw happens and when.

    A lender cannot count on liquidation timing: the loan's 40 % liquidation LTV triggers on Loopscale, but realising the collateral waits on an off-chain issuer onboarding decision. Securitize could also freeze the loan's own collateral account, since the freeze authority stays with it.

    • SECZ mint extensions ↗ · rpc:getAccountInfo 5VzwKkvynPJzcgwhBe7ESEyNgqMbo15yBu7Sehssd9ED jsonParsed: extension defaultAccountState {accountState: frozen}; freezeAuthority 8TwererfKZwiBfKQs2bQmVRrezqeFG3JvrVsbpGaPbQs · checked 2026-09-23T19:22:50Z
    • Liquidation engine token accounts ↗ · rpc:getTokenAccountsByOwner mkr7azob… {mint: SECZ} → 0 accounts (it holds 11 other Token-2022 accounts), slot 449798480 · checked 2026-09-23T19:29:30Z
    • All SECZ token accounts ↗ · rpc:getProgramAccounts Token-2022 memcmp(offset 0 = SECZ mint), slot 449798480: 123 accounts, 90 initialized / 33 frozen; owners checked against mkr7azob…, CyNKPf…, BBEPbs…, bs1PuR…, Hb681P… (none) and against Loopscale-program-owned accounts (only the Loan HUyo5aYaNQvodYmy8TmjnpcxQCk3PVsbyTJUyjmAihFx) · checked 2026-09-23T19:29:30Z
    • Securitize creates and thaws the loan's collateral account (2026-08-10) ↗ · tx 2oPhfmqKgomiEn3swBKtAWXZhXcZtL3neJBYYAuW8UeNwzAdHtNCZzHjZHfXc6Vi2U7P1pM5k9KgkpR27QH1XzW9, slot 438474242, 2026-08-10T21:00:13Z: memo "DSRegistryServiceInvestorAdded 675cd1b765ec9b268dc4385e", DS registry FydSLh… call, ATA create for owner HUyo5a… (account 6Nk983pK7GPa2FyVkj8crq3YQgbXZXA9wPipoBRY4Fhw), then thawAccount signed by freeze authority B2Psxcut8sEVTSEC92ELQfK2veHUuWivuxxHToVq4irF, memo "DSRegistryServiceWalletAdded …" · checked 2026-09-23T19:29:30Z
    • Same registry flow after the program took over the freeze authority (2026-08-12) ↗ · tx 4CYGoHpiNgwNN2WuKFJKBwZ5dmoRaXAT6FWcVh4xxkmTQ5WccHaV5nsGXdwBafSy7caAUiTeJZbjNCBDmvwCE9hV, slot 438818667: FydSLh… → CPI 9yy4W1B5… → thawAccount with freezeAuthority 8Twerer… (PDA), co-signed by B2Psxcut… · checked 2026-09-23T19:22:50Z

Sources

Limits

  • The decode establishes configuration at one finalized slot; the loan is re-snapshotted at every daily refinance and Loopscale's docs say oracles are fixed at origination and cannot change until rollover.
  • The oracle is an end-of-day price with a 65,535 s (about 18 h 12 min) maximum age: intraday moves are not seen, and a price older than that (e.g. over a weekend, if the feed is not rewritten) blocks price-dependent actions rather than being used. The SECZ_EOD value was not reconciled to the NYSE close.
  • Liquidation is not a fixed bonus: Loopscale's docs set the fee at the distance above the liquidation LTV. At the $13.00 oracle price the loan sits at about 0.9 % LTV against a 40 % threshold.
  • No Loopscale liquidator holds a SECZ token account: none of the 123 SECZ accounts belongs to the documented liquidation engine mkr7azob5ee3RC64BVoHQPu7FnyaXzJnLMN8jm942pQ or the admin keys, and SECZ accounts are created frozen (DefaultAccountState), so a liquidation would first need Securitize to thaw the liquidator's account. Securitize thawed this Loan's own account on 2026-08-10, before the loan existed.
  • The oracle type code 19 is stored as a raw u8; neither IDL names the codes. The RedStone attribution rests on the upstream account's owner program and its SECZ_EOD feed id.
  • Loopscale's docs describe the upgrade authority DwBXwJ… as 3-of-5; the chain says threshold 4 of 7 voters with a 24 h time lock.
  • The vault manager and the protocol admin are on-curve keys; whether each is a single person's keypair or custody-managed is not visible on-chain.

A decoded active configuration is stronger evidence than a registry listing. It is still not proof that a particular borrow transaction succeeded.

Custody and default outcomes

Borrower default / seizure

Liquidation is confined to eligible accounts

The lender can receive the registered share only through approved accounts and cannot sell to an arbitrary address or pool. The transfer agent's register and applicable securities restrictions remain authoritative over the liquidation path.

Protocol hack custody

Transfer-agent controls can reverse or contain

Freeze, pause and permanent-delegate controls can immobilise or move the balance after a hack. This may protect the registered owner, but it also means a protocol's on-chain custody and liquidation are subject to transfer-agent intervention.

Access or key loss

The register supports a recovery process

A stranded token can potentially be frozen, cancelled or moved while the shareholder's registered interest is preserved. Recovery still requires identity checks and action by the issuer or transfer agent; the smart contract cannot complete it alone.

These conclusions come from the issuer and control recipe from the matched legal template. They are not protocol simulation results.

Step by step

SECZ on Loopscale: a liquidation that waits for the issuer

New SECZ accounts are born frozen, so seized collateral can go nowhere until Securitize thaws a receiver.
SECZ on Loopscale: a liquidation that waits for the issuer4 actors (Securitize (freeze authority), Loopscale loan, Liquidation engine, Receiving account); 5 numbered steps. 1. Securitize creates and thaws the loan’s collateral account (registering the wallet) (observed) 2. Loan crosses its 40% liquidation LTV; Loopscale triggers liquidation (documented) 3. The liquidation engine holds no SECZ account — and any new one is created frozen (observed) 4. Securitize must thaw a receiving account first — an off-chain onboarding decision with no stated timing (unknown) 5. Only then can the seized SECZ move to the liquidator, lender vault or buyer (unknown)Securitize(freezeauthority)LoopscaleloanLiquidationengineReceivingaccount1Securitize creates and thaws the loan’scollateral account (registering the wallet)2Loan crosses its 40% liquidation LTV;Loopscale triggers liquidation3The liquidation engine holds no SECZ account— and any new one is created frozen4Securitize must thaw a receiving accountfirst — an off-chain onboarding decisionwith no stated timing?5Only then can the seized SECZ move to theliquidator, lender vault or buyer?
  • observed seen by our own checks — on-chain unless the source says otherwise
  • documented the issuer’s or a regulator’s own words
  • not established drawn dashed: nothing found settles it
Steps as text
  1. Securitize (freeze authority) → Loopscale loan Securitize creates and thaws the loan’s collateral account (registering the wallet) observed Source: Observed thaw transaction — slot 438474242, 2026-08-10
  2. Loopscale loan → Liquidation engine Loan crosses its 40% liquidation LTV; Loopscale triggers liquidation documented Source: RWA Sonar research (protocol-market-research)
  3. Liquidation engine The liquidation engine holds no SECZ account — and any new one is created frozen observed Source: Token accounts read on-chain — slot 449798480
  4. Securitize (freeze authority) → Receiving account Securitize must thaw a receiving account first — an off-chain onboarding decision with no stated timing not established Source: RWA Sonar research (protocol-market-research)
  5. Loopscale loan → Receiving account Only then can the seized SECZ move to the liquidator, lender vault or buyer not established Source: RWA Sonar research (protocol-market-research)

Securitize keeps the freeze authority, so it could also freeze the loan's own collateral account. No SECZ liquidation has been observed.

Lender exit after receiving the token

Issuer-dependent exit — Code can hold the balance, but seizure or realisation still depends on issuer recognition, allowlisting, or a claim weaker than possession suggests.

Market-specific dependencies:

Observed DEX liquidity
Not reported
Issuer redemption established
yes
Key limit
Possession of the token does not itself establish eligibility, issuer recognition, redemption access, or enough executable market liquidity.