Spiko · DeFi Risk

DeploymentsStellar · $547.4M

Risk profile at a glance

1 red · 5 yellow · 7 green

Categories & evidence

184 factors · 13 categories

Code & audits Yellow 22 25 of 25

RD-F-007 red Bug bounty presence & max payout No public bug bounty program exists. Immunefi search returns 404. Data cache confirms bug_bounty.platform: null. Profile section 9 confirms no public bounty found after searching Immunefi, Cantina, HackerOne. $1.22B TVS across three codebases with no whitehat economic incentive for disclosure. RD-F-009 red Formal verification coverage No formal verification found across any of the three substrates. No Certora/Kani/Halmos specs in EVM repo. No Cairo-native FV specs. No Kani for Soroban/Rust. Protocol has not declared critical invariants for FV. RD-F-183 red Bug bounty scope gap on highest-TVL contracts No bug bounty program exists (RD-F-007 red). With $1.22B TVS across three codebases and no Immunefi, Cantina, or in-house bounty, there is no whitehat economic incentive for disclosure on the highest-TVL contracts including Stellar (~$547M) and Arbitrum (~$411M). Absence of any program is a superset of the out-of-scope failure mode this factor measures. RD-F-001 yellow Audit scope mismatch Three substrate-specific audits exist: Trail of Bits (EVM, Oct-2023), Nethermind NM0333 (Cairo/Starknet, Dec-2024), Halborn (Stellar/Soroban, Sep-2025 at commit b66c29e). Each covers its substrate at audit time. Material EVM post-audit changes deployed without re-audit: ERC2771 meta-tx (Jan-2024 commit fdd46e1), UUPS proxy upgrade to impl 0x15EA (Apr-2024 tx 0x728d46f2), Minter security requirements (Nov-2025 commit c0b1a75), MultiATM contract (Jan-2026 commits 00b549a through ce96b8b). Deployed EVM bytecode materially diverges from Oct-2023 ToB audit commit. Substrate coverage is complete but EVM temporal coverage has a gap. RD-F-002 yellow Audit recency Halborn Stellar Sep-2025 (8 months ago, green); Nethermind Cairo Dec-2024 (17 months ago, green); Trail of Bits EVM Oct-2023 (31 months ago, yellow/red). EVM substrate covers Arbitrum ~34% + Ethereum ~7% + Polygon ~9% + Base ~2% + Etherlink ~1% = ~53% of TVS with the oldest audit (31 months). Weighted by TVL, audit recency is yellow. RD-F-003 yellow Resolved-without-proof findings Halborn: 5 findings (1 critical, 1 low, 3 informational), all resolved with commit-level evidence (FIND-001 through FIND-005 fixed Sep-22-2025 in stellar-contracts repo). Halborn states 100% remediation. ToB EVM and Nethermind Cairo resolution confirmed at protocol level by Arbitrum STEP-2 application but individual finding-to-commit mapping not independently verifiable without PDF access. Yellow because per-finding on-chain proof is not independently confirmed for ToB/Nethermind. RD-F-006 yellow Audit-to-deploy gap Trail of Bits EVM Oct-2023: initial mainnet launch Jun-12-2024 (~240 days gap, red zone). Halborn Sep-2025: Stellar production deploy Oct-10-2025 (~18 days, green). Nethermind Dec-2024: Starknet was deployed mid-2024, making this a retrospective audit (negative gap). Weighted across substrates: yellow due to EVM gap exceeding 180 days. RD-F-014 yellow Reentrancy guard on external-calling functions ERC-1363 integration (transferAndCall in Token.sol) involves recipient callbacks. OZ ERC20Upgradeable base implements checks-effects-interactions for ERC-1363. ERC2771 meta-tx support (added Jan-2024 post-audit) adds a trusted forwarder pattern. No Slither run to formally confirm no reentrancy path; medium confidence yellow pending tool confirmation. RD-F-015 yellow ERC-777/1155/721 hook without reentrancy guard Token.sol uses ERC-1363 (ERC1363Upgradeable) which provides transferAndCall and transferFromAndCall with recipient callbacks, analogous to ERC-777 hooks. OZ ERC-1363 implementation uses checks-effects-interactions pattern. No ERC-777 or ERC-1155/721 hooks identified. Yellow because ERC-1363 callback integration exists and Slither not run to confirm all paths are guarded. RD-F-024 yellow Code complexity vs audit coverage EVM codebase is compact (Token.sol, Oracle.sol, PermissionManaged.sol, Minter.sol, Redemption.sol + extensions). ToB Oct-2023 covered pre-launch codebase. Post-audit additions: ERC2771 (Jan-2024), MultiATM (Jan-2026, ~220 LOC changes). Cairo: 3 contracts, Nethermind covered. Stellar: 5 contracts, Halborn covered. Qualitatively moderate complexity; MultiATM is unaudited complexity concern but non-core. RD-F-010 gray Static-analyzer high-severity count No published Slither/Mythril/Semgrep output available. EVM source is verified on Etherscan. Slither not run locally per T-10 dry-run constraint. Cairo contracts are not Slither-parseable. Soroban/Rust requires cargo-audit/clippy not Slither. Cannot assess without tool run.

RD-F-004 green Audit count Three distinct audit firms: Trail of Bits (EVM Solidity), Nethermind Security (Cairo/Starknet), Halborn (Stellar/Soroban). All three are substrate-specific and publicly accessible. Three firms across three substrates.

RD-F-005 green Audit firm tier Trail of Bits is Tier-1. Nethermind Security is Tier-2 (established firm with large public audit portfolio). Halborn is Tier-2 (established, known for Stellar/Soroban work). At least one Tier-1 firm covers the EVM substrate.

RD-F-008 green Ignored bounty disclosure No prior incidents per data cache rekt.incidents: []. No post-mortem exists. Clean incident history confirmed by profile section 10. With no prior incidents, no ignored bounty disclosure is possible.

RD-F-011 green SELFDESTRUCT reachable from non-admin path No SELFDESTRUCT opcode found in reviewed EVM contracts (Token.sol, Oracle.sol, PermissionManaged.sol). UUPS upgrade pattern without selfdestruct. Cairo and Soroban do not have SELFDESTRUCT equivalent. Source inspection of key contracts confirmed no selfdestruct paths.

RD-F-012 green delegatecall with user-controlled target No delegatecall with user-controlled target found. UUPS upgradeToAndCall is gated by _authorizeUpgrade with restricted() modifier checking Permission Manager. No user-supplied target delegatecall patterns in Token.sol, Oracle.sol, or PermissionManaged.sol.

RD-F-013 green Arbitrary call with user-controlled target No arbitrary .call(target, data) with user-controlled target found in reviewed EVM contracts. Contract architecture uses restricted function calls through Permission Manager with no exposed arbitrary external call surfaces.

RD-F-016 green Divide-before-multiply pattern No divide-before-multiply patterns identified in core Token/Oracle contracts. Oracle uses Checkpoints.Trace208 for price storage without problematic division in price path. Minter daily limits use simple integer comparisons. Slither not run to fully confirm.

RD-F-017 green Mixed-decimals math without explicit scaling USTBL and EUTBL use 5 decimals confirmed from deploy tx. Oracle publishes prices as uint208. Each token is independent with its own oracle. No cross-token arithmetic path identified. No mixed-decimal arithmetic found.

RD-F-018 green Signed/unsigned arithmetic confusion No signed integer usage identified in Token.sol or Oracle.sol. OZ v5.4.0 base contracts are well-reviewed for signed/unsigned issues. No evidence of signed/unsigned confusion in reviewed source. Slither not run.

RD-F-019 green ecrecover zero-address return unchecked Token.sol inherits ERC20PermitUpgradeable from OZ v5.4.0. OZ ECDSA library in v5.x includes the address(0) check for ecrecover by construction. No direct ecrecover calls in Token.sol. OZ 5.x Permit implementation is well-audited.

RD-F-020 green EIP-712 domain separator missing chainId Token.sol uses ERC20PermitUpgradeable (EIP-2612). OZ ERC20PermitUpgradeable in v5.x includes chainId in domain separator by construction per EIP-712. Contract deployed across multiple EVM chains (Ethereum, Arbitrum, Polygon, Base) - chainId in domain separator prevents cross-chain replay.

RD-F-021 green UUPS _authorizeUpgrade correctly permissioned Token.sol _authorizeUpgrade: restricted to Permission Manager authority via `_checkRestricted(UUPSUpgradeable.upgradeToAndCall.selector)`. Oracle.sol: same pattern. Both correctly gate upgrades through the permission manager's access control. Not open to arbitrary callers.

RD-F-022 green Public initialize() without initializer modifier EVM Token.sol constructor calls _disableInitializers() and initialize() carries public initializer() modifier. This is the correct OZ UUPS pattern preventing re-initialization attacks. Verified from Token.sol source directly. USTBL proxy upgrade tx shows Initialized event version 1 confirming proper init.

RD-F-023 green Constructor calls _disableInitializers() EVM Token.sol constructor explicitly calls _disableInitializers(). USTBL Ethereum proxy upgrade tx (Apr-19-2024) shows Initialized event version 1. OZ UUPS pattern correctly implemented.

Governance & admin Yellow 38 24 of 24

RD-F-028 red Low-threshold multisig vs TVL [CRITICAL] 2-of-5 Safe threshold at $1.22B TVS. Peer norm for >$1B TVL is 5-of-8 or higher. Compromise of any 2 of 5 signers (all unidentified publicly) enables immediate contract upgrade with no timelock delay. Arbitrum STEP-2 application confirms Safe but discloses no address, threshold, or signers. Governance opacity compounds the low-threshold risk. RD-F-032 red Timelock duration on upgrades No timelock on any chain. Data cache confirms governance.timelock_address: null. Tech blog and Arbitrum STEP-2 application both describe direct multisig control with no delay. Upgrades executable immediately on 2-of-5 signatures. RD-F-033 red Timelock on sensitive actions No timelock on any action category (mint/pause/rescue/setOracle/upgrade). All privileged actions route through Permission Manager roles gated by the 2-of-5 Safe with no on-chain delay. Pause function callable immediately by exceptional-operator. RD-F-025 yellow Admin key custody type Admin is a Gnosis Safe multisig (2-of-5) at 0xEBB418e1f8E8F26BdF7816A2cD25bE87c040E425 with no timelock. Classified as multisig-no-timelock. Safe confirmed GnosisSafeProxy 1.3.0 on Etherscan. Tech blog confirms multisig-controlled super-admin. RD-F-026 yellow Upgrade multisig signer configuration (M/N) 2-of-5 Safe at 0xEBB418e1f8E8F26BdF7816A2cD25bE87c040E425. Five owner addresses confirmed via Safe API. None publicly attested by name. required=2, total=5. RD-F-027 yellow Single admin EOA Admin is not an EOA. Effective upgrade/owner role held by 2-of-5 Gnosis Safe (0xEBB418e1f8E8F26BdF7816A2cD25bE87c040E425). Not a single admin EOA. Threshold critically low vs $1.22B TVS (captured in F028). RD-F-034 yellow Guardian/pause-keeper distinct from upgrader Pause/exceptional-operator role is structurally distinct from super-admin/upgrade role in the Permission Manager. However both are ultimately manageable by the same 2-of-5 Safe (super-admin can reassign any role). RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle Permission Manager defines distinct roles for upgrade (super-admin), minting (daily-operator), and oracle (oracle-operator). Role separation is administrative. Super-admin can reassign any role, making separation soft rather than cryptographic. RD-F-041 yellow Rescue/emergencyWithdraw without timelock No explicit rescue/emergencyWithdraw function found in EVM token ABI. Pause function exists (exceptional-operator, no timelock). Not a direct fund-drain vector. Admin can freeze token transfers immediately without delay. RD-F-042 yellow Admin has mint() with unlimited max mint(address, uint256) exists in token ABI with no observable supply cap. Minting gated by daily-operator role (not super-admin directly). Super-admin can reassign daily-operator. AMF regulatory constraints limit unconstrained issuance in practice. Current USTBL supply ~52.8M tokens visible on Etherscan. RD-F-029 gray Multisig signers co-hosted Five signer addresses are not publicly attested. Cannot assess co-hosting from available data. RD-F-030 gray Hot-wallet signer flag Cannot assess hot-wallet status of signers; their identities are not publicly disclosed and on-chain tx pattern analysis was not conducted. RD-F-031 gray Signer rotation recency No Safe event history analyzed; data cache safe_multisigs empty (pipeline did not capture this Safe). No public signer rotation events found. RD-F-036 n/a Flash-loanable voting weight No on-chain Governor, no governance token, no DAO. Corporate-governed RWA issuer. PD-042 applies. RD-F-037 n/a Quorum achievable via single-entity flash loan No on-chain governance quorum. Corporate-governed RWA issuer per PD-042. RD-F-038 n/a Proposal execution delay < 24h No governance proposals or execution path. Corporate-governed per PD-042. RD-F-039 n/a delegatecall/call in proposal execution without allowlist No governance executor contract or proposal execution path. Corporate-governed per PD-042. No delegatecall surface in a governance context. RD-F-040 n/a Emergency-veto multisig present No on-chain Governor to veto. Exceptional-operator pause is an analog but serves a different function. Not a veto mechanism in the governance sense. RD-F-044 gray Admin wallet interacts with flagged addresses Safe signer addresses not analyzed against Chainalysis/OFAC watchlists within this assessment. RD-F-047 n/a Governance token concentration (Gini) No governance token. Spiko tokens are AMF-regulated fund shares, not governance tokens. Investor governance is off-chain per French corporate law.

RD-F-043 green Admin = deployer EOA after 7 days Deployer EOA (0xed608cf38968c0ba09676843d90b33dd59dd7375) is not the super-admin. Admin transferred to Permission Manager + 2-of-5 Safe architecture. Deployer EOA last active 73 days ago on operational Set Chain Rate transactions, not governance operations.

RD-F-045 green Constructor args match governance proposal Constructor args (authority=0x344278af, trustedForwarder=0x42DB5A5A) are publicly visible and match the deployed Permission Manager proxy and ERC2771Forwarder in the same deployment sequence. No governance proposal required for corporate-governed protocol; args are verifiable on-chain.

RD-F-046 green Contract unverified on Etherscan/Sourcify All core EVM contracts source-verified on Etherscan: USTBL proxy (0xe4880249), EUTBL proxy (0xa0769f7a), Permission Manager proxy (0x344278af), impl (0xd3f5f152), token impl (0x15EA0EC4). GitHub repos for Starknet and Stellar are public. For RWA issuer: team-discretion-vs-published-process reframe per PD-042; AMF regulatory oversight is accountability layer.

RD-F-167 green Deprecated contract paused but pause reversible by live admin No deprecated contracts identified. Protocol is 23 months old with no confirmed full contract migration or deprecated surfaces. No admin-pausable deprecated contracts found.

Oracle & external dependencies Yellow 30 17 of 17

RD-F-180 red Immutable oracle address [STAR CRITICAL-CANDIDATE — FLAG FOR T-14] ATM3.sol declares 'Oracle immutable public oracle;' — oracle address set at construction, cannot be replaced by any admin action. No setOracle function. No admin-replaceable wrapper exists in ATM3. This is a confirmed EVM immutable keyword usage per the F180 definition (PD-023). Partial mitigation: MultiATMLinear.sol (newer) stores oracle in mutable _pairs mapping with setPair() allowing replacement. Risk depends on which contract variant handles live subscriptions/redemptions. Trail of Bits Oct 2023 audit covered ATM3 but immutability was not flagged as a remediation item. RD-F-049 yellow Oracle role per asset Single Oracle contract per EVM token acts as Primary feed via latestRoundData(). No secondary or fallback oracle exists. Non-EVM (Stellar, Starknet) oracle role is unknown — reduces confidence to yellow. RD-F-050 yellow Dependency graph (protocols depended upon) EVM dependency graph: Chainlink CCIP (cross-chain), Oracle contract + oracle-operator relayer (NAV feed), CACEIS fund administrator (off-chain data source), PermissionManager (access control). Non-EVM dependency graph (Stellar 45% TVL, Starknet 3% TVL) is undocumented. Critical path: CACEIS + oracle-operator failure halts subscriptions/redemptions on all EVM chains. RD-F-051 yellow Fallback behavior on oracle failure ATM3.sol and MultiATMLinear.sol revert (halt) if oracle is stale beyond oraclettl. No fallback to secondary source — just revert. Users cannot subscribe or redeem when oracle is stale (weekends, holidays). No last-known-price mode. This is a known operational gap for business-day-only NAV publishing. RD-F-052 yellow Breakage analysis per dependency Oracle staleness: subscription/redemption contracts revert; underlying T-bill holdings unaffected (off-chain AMF fund). CCIP failure: cross-chain transfers halt; single-chain operations continue. CACEIS failure: NAV not publishable; all on-chain pricing becomes stale at next business day. ATM3 oracle cannot be replaced by admin action — only full contract redeployment restores oracle if the feed address changes. RD-F-057 yellow Circuit breaker on price deviation No price deviation circuit breaker identified in Oracle.sol, ATM3.sol, or MultiATMLinear.sol. Only staleness check (oraclettl) is present. No halt-on-NAV-deviation mechanism. For an issuer-attested oracle this is less critical than for DEX-price protocols, but the absence is notable. RD-F-062 yellow External keeper/relayer not redundant Spiko's NAV publishing relies on an internal oracle-operator relayer as primary publisher. Chainlink Labs provides a secondary publishing path (redundancy). However no automated failover between the two is documented. If Spiko's internal relayer fails, Chainlink Labs must independently detect and fill the gap. Weekend/holiday gaps are known (business-day-only NAV). Not a traditional keeper/automation network. RD-F-054 n/a TWAP window duration Spiko uses issuer-attested NAV oracle, not a DEX TWAP. TWAP window concept does not apply. Staleness is controlled by oraclettl parameter in ATM3/MultiATMLinear contracts. RD-F-055 n/a Oracle pool depth (USD) No DEX pool underlies the oracle. NAV is an off-chain administrative value from CACEIS fund administrator. Pool depth concept does not apply. RD-F-056 n/a Single-pool oracle (no medianization) Single-pool oracle medianization concept does not apply — no DEX pool. Spiko has dual publishing paths (Spiko relayer + Chainlink Labs) but these are sequential publishers to the same Oracle contract, not medianized across venues. RD-F-058 n/a Max-deviation threshold (bps) No circuit breaker configured, so no threshold to measure. Circuit breaker (F057) is absent; this field has no applicable value. RD-F-060 n/a Chainlink aggregator min/max bound misconfig Spiko's Oracle contract is a custom implementation of AggregatorV3Interface, not a standard Chainlink aggregator with minAnswer/maxAnswer circuit breakers. The minAnswer/maxAnswer misconfig factor applies to standard Chainlink feed contracts, not to custom implementors of the interface. RD-F-061 n/a LP token balanceOf used for pricing No LP tokens or balanceOf-based pricing in Spiko. NAV is published by oracle-operator via publishPrice(). ATM3 _getPrices() only calls oracle.latestRoundData() — no balanceOf dependency. RD-F-181 n/a Permissionless-pool lending oracle Spiko is an RWA token issuer (AMF-regulated UCITS MMF), not a lending protocol. F181 applies to lending protocols accepting spot prices from permissionless DEX pools for collateral. No lending functionality, no collateral-acceptance logic, no borrowing in Spiko's protocol.

RD-F-048 green Oracle providers used Spiko uses a proprietary Oracle contract implementing Chainlink AggregatorV3Interface, fed by CACEIS fund administrator NAV data published by an internal oracle-operator relayer and cross-published by Chainlink Labs. No Pyth, Redstone, or Uniswap-TWAP. Stellar and Starknet oracle providers undocumented (gray subset).

RD-F-053 green Oracle source = spot DEX pool (no TWAP) [STAR CRITICAL] Not a spot DEX oracle. Spiko Oracle contract receives NAV data from CACEIS fund administrator via Spiko oracle-operator relayer. Published via publishPrice(uint48 timepoint, uint208 price) gated by restricted() modifier (ORACLE role). No DEX pool consulted. No AMM price. No flash-loan manipulation vector. Issuer-attested NAV is the most manipulation-resistant oracle design for RWA tokens.

RD-F-059 green Oracle staleness check present Staleness check present: ATM3.sol require(block.timestamp < updatedAt + oraclettl, 'oracle value too old'); MultiATMLinear.sol require(block.timestamp < updatedAt + oracleTTL, OracleValueTooOld(oracle)). Both subscription/redemption contracts validate oracle recency before using price data. oraclettl is configured at construction.

Economic risk Yellow 22 13 of 13

RD-F-064 yellow TVL concentration (top-10 wallet share) Spiko reports 'over 1,000 active investors, including over 500 legal entities' as of March 2025 (Arbitrum STEP-2 application), but top-10 wallet concentration is not publicly disclosed. Tokens are KYC-whitelisted — transfers are restricted to approved addresses — which structurally limits retail distribution and increases institutional concentration probability. No on-chain holder scan was performed across all 7 chains within evidence budget. Scored yellow: institutional-tier concentration likely meaningful but not quantified. RD-F-065 yellow Liquidity depth per major asset Secondary market liquidity for USTBL/EUTBL is effectively zero: tokens are KYC-whitelisted (transfer-restricted) with no public AMM pool or on-chain order book. Primary-market redemption via Spiko's platform is the only viable exit route: daily window, 10:30 CET cutoff, same-day or next-business-day NAV execution. Weekend/holiday orders queue to next business day (up to ~3-day NAV staleness window). 44.97% of TVS is on Stellar, where the Stellar-to-EVM bridge step for primary-market redemption is undefined in available public documentation. Underlying T-bills have ~43-day weighted average maturity; settlement lag is implied ~T+1 but not explicitly stated. These are structural features of regulated securities, not exploitable vulnerabilities, but they represent real illiquidity constraints vs. instant on-chain exit. RD-F-066 n/a Utilization rate (lending protocols) Spiko is an RWA token issuer (AMF-regulated UCITS MMF). No lending markets, no borrow positions. Data cache confirms borrow.present: false, total_borrowed_usd: null, utilization_rate_pct: null. Lending-only factor per taxonomy PD-024. RD-F-067 n/a Historical bad-debt events No lending or collateral-backed borrow structure; no mechanism for bad debt to arise. Protocol is a UCITS fund token issuer. Lending-only factor per taxonomy PD-024. RD-F-068 n/a Collateralization under stress Fund holds ~93% US T-bills and ~7% bank deposits (CACEIS/JPMorgan Chase); no collateral/borrow structure. Portfolio is fully backed by sovereign instruments. UCITS rules require full asset coverage. No stress-scenario collateralization ratio applies. Lending-only factor per taxonomy PD-024. RD-F-069 n/a Algorithmic / under-collateralized stablecoin USTBL and EUTBL are NAV-accruing yield tokens representing UCITS fund units. The price rises continuously as T-bill yield accrues; there is no algorithmic peg mechanism, no seigniorage design, no under-collateralized architecture. Not in the Terra/Luna or Basis-style stablecoin class. Lending-only/algorithmic-stablecoin-specific factor per taxonomy PD-024. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) RD-F-070 ★ critical factor is explicitly 'Compound-fork-only' per taxonomy §Category 4 PD-024. Spiko is an original implementation (profile §5: 'Not forked / original'), not a Compound V2 fork, and has no cToken-style market structure. No lending markets exist. The data cache confirms borrow.present: false. The circle-usyc calibration precedent (first RWA fill in this pipeline) established the same not_applicable ruling for RWA-issuer protocols. No critical-factor penalty applies. RD-F-071 n/a Seed-deposit requirement for new market listing No market-listing mechanism exists. Fund series are launched by Spiko as a corporate decision (AMF-approved prospectus), not by on-chain seed deposit or governance vote. Lending-only factor per taxonomy PD-024. RD-F-072 n/a Market-listing governance threshold No new market-listing governance exists. Fund structure is governed by AMF-approved prospectus; new share classes are regulatory decisions, not on-chain governance votes. Lending-only factor per taxonomy PD-024. RD-F-073 n/a Oracle-manipulation-proof borrow cap No borrow positions, no oracle-determined borrow caps. The NAV oracle (Chainlink AggregatorV3Interface at 0x903d5990119bC799423e9C25c56518Ba7DD19474 on Ethereum) is for token pricing, not borrow cap enforcement. Lending-only factor per taxonomy PD-024. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) USTBL/EUTBL are not ERC-4626 vaults. They are ERC-20 tokens (and Stellar/Starknet equivalents) representing registered UCITS fund units. NAV accounting is managed off-chain by the fund administrator; no share-inflation attack surface exists. Lending-vault-specific factor per taxonomy PD-024. RD-F-075 n/a First-depositor / share-inflation guard Not a share-based vault; not susceptible to first-depositor inflation attacks. Token supply is minted/burned by whitelisted MINTER/BURNER roles (Spiko's own controlled process via Permission Manager), not by permissionless user deposit calls. No share-accounting attack surface exists. Lending-vault-specific factor per taxonomy PD-024.

RD-F-063 green TVL (current + 30d trend) TVS $1,217,270,512 as of 2026-05-15; +2.21% over 30 days; 90-day CoV = 0.056 (mean $1.161B, std $64.8M, 90-sample window). Sustained monotonic growth from ~$29M at launch (Aug 2024) to $1.22B — a 42x increase in ~21 months. 12-month peak $1,264,422,003. Trend and stability are both healthy.

Operational history Green 9 15 of 15

RD-F-089 red Insurance coverage active No active smart-contract insurance coverage found on Nexus Mutual, Sherlock, or Unslashed for Spiko, EUTBL, or USTBL. Immunefi does not list a Spiko program. Web search for 'Spiko Nexus Mutual OR Sherlock OR Unslashed' returns no results linking Spiko to any DeFi insurance provider. $1.22B TVS across seven chains with zero coverage is a structural gap. This mirrors the circle-usyc precedent (same finding, same conclusion). No self-insurance disclosure found in any public source. RD-F-081 gray Post-exploit response score No prior incidents exist; post-exploit response score (1–5 curator-scored) cannot be assessed against a non-existent last incident. Gray per methodology template: 'no prior incidents, cannot assess'. Excluded from rubric denom. RD-F-082 gray Post-mortem published within 30 days No prior incidents; no post-mortem can be published for an event that did not occur. Factor is episodic (E cadence) and cannot be assessed without a triggering incident. Gray per methodology template. Excluded from rubric denom. RD-F-083 gray Auditor re-engaged after last exploit No prior exploit; auditor re-engagement criterion cannot be assessed. Episodic factor that requires a triggering exploit event. Gray per methodology template. Excluded from rubric denom. Note: Halborn was engaged for the Stellar contracts (Sep 2025) but this was a proactive new-codebase audit, not a post-exploit re-engagement. RD-F-085 gray Incident response time (minutes) No prior incidents; incident-response-time metric (minutes from exploit tx to first official statement) is not computable without a triggering incident. Episodic factor. Gray per methodology template. Excluded from rubric denom.

RD-F-076 green Protocol age (days) Spiko launched 2024-06-12; 704 days live as of 2026-05-16. Exceeds the 365-day green threshold. First DefiLlama daily TVL data point 2024-08-13 (~$28.7M). Protocol has operated continuously across seven chains with monotonically growing TVS.

RD-F-077 green Prior exploit count Zero confirmed incidents. Hacksdatabase grep for 'spiko', 'eutbl', 'ustbl' returns 0 results across all 23+ batches. Data-cache rekt.incidents is empty. Rekt.news frontpage and search return no Spiko articles. Spiko blog contains no post-mortems or incident disclosures. Web OSINT finds no exploit, redemption halt, CCIP-related loss, depeg event, or governance attack across EVM, Starknet, or Stellar. Clean record through 23 months of operation.

RD-F-078 green Chronic-exploit flag (≥3 incidents) Zero exploits total; chronic threshold of 3 incidents not met. Derived from F077 evidence.

RD-F-079 green Same-root-cause repeat exploit No exploits of any kind; same-root-cause repeat criterion cannot be triggered. Zero incidents confirmed across hacksdatabase, rekt.news, and data-cache.

RD-F-080 green Days since last exploit Display-only derivative of F077. No prior exploits exist; days-since-last-exploit is N/A. Displayed as clean.

RD-F-084 green TVL stability (CoV over 90d) Data-cache tvl_cov_90d.cov = 0.055803 (mean $1.161B, std $64.8M over trailing 90 days). This is very low volatility — consistent with monotonically growing institutional inflows from ~$1.03B (Feb 2026) to $1.22B (May 2026). No TVL drops, spikes, or discontinuities indicative of operational stress.

RD-F-086 green Pause activations (trailing 12 months) No deliberate pause activations found in trailing 12 months. Spiko has a PAUSER role in its Permission Manager, but no pause activation has been documented on any public channel (blog, Twitter/X, on-chain events, GitHub). DefiLlama TVL series shows no sudden-drop events consistent with a pause. Corporate governance structure makes a pause a material reportable event — the absence of any such report supports green.

RD-F-087 green Pause > 7 consecutive days No pause of any duration found; the >7-consecutive-days threshold is not triggered. Same evidence base as F086. DefiLlama TVL series shows no period of zero TVL or extended operational halt.

RD-F-088 green Re-deployed to new addresses in last year No redeployment to new contract addresses found. UUPS upgrade transactions noted in profile (USTBL proxy on Ethereum upgraded 2024-04-19, EUTBL proxy on Arbitrum upgraded 2024-10-25) but UUPS upgrades update the implementation behind the same proxy address — they are not contract redeployments for F088 purposes. The proxy addresses in the production set are unchanged. No new-address migration event or user-migration announcement found.

RD-F-166 green Deprecated contracts still holding value No officially deprecated contracts identified. Spiko is 23 months into its first-generation architecture, actively expanding (new chain deployments Jan 2025, Sep-Oct 2025, Feb 2025). No deprecation announcements found on spiko.io/blog, tech.spiko.io, or GitHub. All proxies in the profile contract table are active production contracts with live TVS. F166 green.

Real-time signals Green 17 22 of 22

RD-F-098 green TVL anomaly — % drop in <1h TVL $1.217B with 90-day CoV = 0.0558 (monotonic growth, low volatility). 30d change +2.21%, 1d change +3.15%. No drop event in trailing 90-day daily series. Threshold: TVL_now / TVL_baseline_30d < 0.70 over 60-minute window. Current posture well above threshold. Signal applicable and would not fire today.

RD-F-105 green DNS/CDN/frontend hash drift spiko.io registered 2023-10-02 via Amazon Registrar; last updated 2026-04-29 (benign — likely routine cert/DNS maintenance). spiko.vercel.app is the on-chain dashboard frontend. No DNS drift, TLS cert anomaly, or frontend hash change identified in available public sources. Signal applicable; T-09 phase 2 infrastructure required for production alerting.

Dev identity & insider risk Green 12 16 of 16

RD-F-117 red ENS/NameStone identity bound to deployer No ENS or NameStone name bound to deployer address 0xed608cf38968c0ba09676843d90b33dd59dd7375. Etherscan shows no ENS tag. The deployer is a corporate operational wallet; ENS binding is not standard practice for institutional deployers. Scored red per factor definition. Low risk-signal value in context of AMF-regulated doxxed-team protocol — mechanical finding only. RD-F-114 yellow Deployer address prior on-chain history Deployer 0xed608cf38968c0ba09676843d90b33dd59dd7375 labelled 'Spiko: Deployer' on Etherscan. 244 txs, all Spiko-related (contract deploys, role grants, operational calls). First tx April 2024. No prior non-Spiko deploys visible. No Chainalysis/Nansen rug-deployer label. Scored yellow per taxonomy: fresh address (no prior history outside Spiko). This is neutral, not flagged. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Spiko is a corporate-governed no-DAO RWA issuer (PD-042 class). No public governance forum exists. Admin changes executed via 2-of-5 super-admin Safe (0xEBB418e1f8E8F26BdF7816A2cD25bE87c040E425) as routine corporate operations. USTBL proxy upgraded 2024-04-19; EUTBL Arbitrum upgraded 2024-10-25; no public pre-discussion for either. GitHub PR#23 (admin sanity-check config, April 2024) minimal discussion. No sudden unannounced emergency-rescue or ACL escalation detected in 180-day trailing window. Scored yellow per PD-042: absence of forum is structural to corporate governance model, not a red departure from stated norms. No Drift-class insider-implant signal detected. RD-F-122 gray Contributor paid to DPRK-cluster wallet Spiko pays staff via off-chain corporate payroll (French SAS entity). No on-chain contributor payment streams (salary, grants, vesting contracts) are visible on the deployer or admin Safe. Without a paid Chainalysis/TRM CTI feed, mechanical 3-hop path analysis from contributor wallet addresses to DPRK-labeled cluster cannot be performed. Scored gray; if contributor payment addresses are identified, curator should re-assess. RD-F-184 gray Real-capital social-engineering persona No curator-flagged real-capital social-engineering persona detected. Spiko has operated publicly since June 2024 with a regulated named-team structure. No external 'contributor' or 'integrator' persona with unexplained large capital deposits has been flagged in OSINT or incident reporting. Per process-learnings guidance, F184 is marked gray because: (a) confirming absence of a covert social-engineering persona requires cross-source verification beyond public OSINT; (b) by design such personas leave no public trace until the attack. Reference comparator: Drift Protocol UNC4736 6-month $1M+ capital-deposit persona build-up prior to April 2026 DPRK exploit. No analogous pattern detected for Spiko.

RD-F-111 green Team doxx status 6 named team members all real-name with verifiable prior professional histories. Founders Hyppolite (former French Treasury Deputy Head, ENS/Polytechnique) and Michon (former ministerial digital advisor and Palantir, Polytechnique) are doxxed public figures. CTO Briole and engineer Assouad have LinkedIn profiles and GitHub histories. Legal head Charpiat is named in Arbitrum STEP-2 application. AMF-regulated entity (Spiko SAS, ACPR #19183) provides institutional identity anchor.

RD-F-112 green Team public accountability surface Each core team member has ≥3 verifiable public trails. Hyppolite: LinkedIn, France FinTech bio, Harvard CES researcher page, Cairn.info academic publications, Crunchbase, LinkedIn activity posts. Michon: LinkedIn, STEP-2, tech blog author. Briole: LinkedIn, STEP-2, blog. Assouad: LinkedIn, GitHub fondation451 (40+ repos), blog posts (5 articles). Regulatory entity (ACPR #19183, AMF supervision) adds institutional accountability layer.

RD-F-113 green Team other-protocol involvement history No prior rug or exit-scam affiliations found for any team member. Hyppolite: French Treasury / ENS. Michon: French government / Palantir. Briole / Assouad: software engineers, no DeFi protocol launches before Spiko. External contributor Hadrien Croubois is an established OpenZeppelin smart contracts engineer. Web search for 'Spiko rug exit scam fraud' returned zero results. No rekt.news entry. No hacksdatabase match.

RD-F-115 green Prior rug/exit-scam affiliation No team member linked to prior rug or exit-scam. Web search 'Spiko rug exit scam fraud 2024 2025' returned zero matches for Spiko as an entity. No rekt.news Spiko incident. Hacksdatabase search returns no Spiko entries (per 00-profile.md §10). Founders have verified government/corporate prior employment histories incompatible with the rug-deployer behavioral profile.

RD-F-116 green Contributor tenure at admin-permissioned PR Most recent admin-permissioned code merge: PR#53 'Multiatm' merged 2026-01-07, authored by fondation451 (Nicolas Assouad). GitHub API commit history confirms Assouad active in spiko-tech/contracts repo since at least September 2025 (commits at 2025-09-29 and later). Repo created ~2 years before assessment date. Assouad's estimated tenure in repo ≥6 months at time of most recent admin-permissioned PR.

RD-F-118 green Handle reuse across failed/rugged projects No social handle (Twitter @Spiko_finance, team LinkedIn handles) associated with a prior rugged or failed project. Twitter handle @Spiko_finance is unique to Spiko. Web search for team names + 'rug' returned no results. No Wayback Machine alias reuse detected.

RD-F-119 green Commit timezone consistent with stated geography GitHub API commit timestamps for spiko-tech/contracts (20 most recent, 2025-09 to 2026-03): UTC hours range 09–18. Paris CET (UTC+1) / CEST (UTC+2) working hours map to 08:00–17:00 UTC in summer and 08:00–18:00 UTC in winter. Observed commit distribution fully consistent with Paris timezone. Primary committers: Adam Hotait (09–18 UTC), Nicolas Assouad (12–15 UTC), Antoine Mch (13 UTC). No UTC+9 anomaly (DPRK/Tokyo signature).

RD-F-120 green Video-off/voice-consistency flag Founders have public media presence with named identities. Hyppolite has LinkedIn video posts (Series A announcement July 2025). French press coverage (cryptoast.fr, finascope.fr, Silicon Canals, EU-Startups) names and identifies founders consistently. Regulatory filings (ACPR, AMF) require real-identity disclosure. No reports of video-off patterns or voice inconsistencies in any available public appearance.

RD-F-121 green Contributor OSINT depth score Curator OSINT depth scores per contributor: Hyppolite 5/5 (LinkedIn full history, France FinTech bio, Harvard CES page, Cairn.info publications, Crunchbase, LinkedIn video activity); Michon 4/5 (LinkedIn, STEP-2, blog); Briole 3/5 (LinkedIn, STEP-2, blog); Assouad 4/5 (LinkedIn, GitHub fondation451 40+ repos, 5 blog posts); Charpiat 3/5 (STEP-2 named). Average: 3.8/5. Meets green threshold (≥3 per core member).

RD-F-124 green Deployer wallet mixer-funded within 30 days Deployer 0xed608cf38968c0ba09676843d90b33dd59dd7375 funded 2024-04-19 (~54 days before June 2024 launch). Funding source: 0xe67D2cbeae3090be017c66e7a6943961619a5d35 (Gnosis Safe, 80 txs, labeled 'Smart Account by Safe' on Etherscan). No Tornado Cash, Railgun, or privacy-mixer label on the deployer or its 1-hop funder. No mixer withdrawal event within the 30-day pre-deploy window. Etherscan internal-tx tab confirms 'Funded By' = this Gnosis Safe with no mixer interaction in the chain.

RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No path found from deployer or admin Safe to any DPRK/Lazarus-labeled address. Structural identity anchors: AMF/ACPR-regulated French SAS (ACPR #19183), founders are former French civil servants with verified government employment. Web search 'Spiko DPRK Lazarus North Korea' returned zero matches for Spiko as an entity or team. OFAC SDN search returned no matches for Spiko-associated addresses. Funding chain: Safe → Safe → deployer, no flagged labels at any hop. Note: mechanical 3-hop graph traversal limited by absence of paid CTI feed; evidence-of-absence plus regulatory-identity anchor applied per circle-usyc precedent.

Fork / dependency lineage Green 11 10 of 10

RD-F-133 yellow Dependency manifest uses unpinned versions EVM package.json uses caret versioning: @openzeppelin/contracts ^5.4.0 and @chainlink/contracts ^0.8.0 - allows minor/patch updates, not exact pinning. This is a yellow finding per taxonomy (OZ and Chainlink not pinned to exact versions). Soroban Cargo.toml pins soroban-sdk to exact version 22.0.8 (green). Cairo package management not directly inspected. RD-F-126 n/a Is-a-fork-of Spiko is an original implementation across all three substrates. GitHub repos have no fork declaration. README describes purpose-built tokenized securities contracts. OZ is used as a library dependency, not a fork base. Not applicable. RD-F-127 n/a Upstream patch not merged Not a fork - no upstream to track patches from. OZ is a library dependency tracked separately under F135. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) Not a fork - no upstream vulnerability disclosures to track. RD-F-129 n/a Code divergence from upstream (%) Not a fork - no upstream to diff against. RD-F-130 n/a Fork depth (generations from original audit) Not a fork - fork depth undefined for original implementation. RD-F-131 n/a Fork retains upstream audit coverage Not a fork - each codebase has independent substrate-specific audits (ToB EVM, Nethermind Cairo, Halborn Stellar). No upstream audit to inherit. RD-F-132 n/a Fork has different economic parameters than upstream Not a fork - no upstream defaults to compare economic parameters against.

RD-F-134 green Dependency had malicious-release incident (last 90d) No GitHub Security Advisories flagging malicious releases in OZ v5.4.x, Chainlink contracts ^0.8.x, or soroban-sdk 22.0.8 in trailing 90 days as of 2026-05-16. No known npm or crates.io malicious-release incidents for these packages.

RD-F-135 green Shared-library version with known-vuln status OZ v5.4.0: No high/critical GHSA advisories for this version as of 2026-05-16. OZ 5.x is current supported release. Soroban SDK 22.0.8: No known critical advisories. Chainlink contracts ^0.8.0: widely used, no active critical advisories.

Post-deploy hygiene & change mgmt Yellow 21 13 of 13

RD-F-139 red Post-audit code changes without re-audit [CRITICAL] Trail of Bits audit October 2023. Two post-audit EVM upgrades deployed without re-audit: (1) USTBL Ethereum 2024-04-19 impl to 0x15EA0EC4; (2) EUTBL Arbitrum 2024-10-25. Nethermind covers Starknet only; Halborn covers Stellar only. No EVM re-audit found covering post-2023 deployed code. Euler lineage failure pattern. RD-F-136 yellow Deployed bytecode matches signed release tag No signed git release tags found in spiko-tech/contracts GitHub repo. Hardhat-based build; no Foundry deterministic build artifacts. Bytecode matching against a signed release cannot be confirmed. Last commit 2026-03-03. RD-F-137 yellow Upgrade frequency (per 90 days) Two EVM upgrades identified in protocol history (USTBL Ethereum 2024-04-19; EUTBL Arbitrum 2024-10-25). No upgrades in trailing 90 days. Stellar post-Halborn remediation also constitutes an upgrade cadence event. Upgrade frequency is not excessive but each upgrade lacks timelock. RD-F-142 yellow Storage-layout collision risk across upgrades UUPS proxy with OZ v5.4.0. No public OZ upgrades-plugin storage layout validation output found. Risk acknowledged but no confirmed collision identified. RD-F-145 yellow Deployed bytecode reproducibility Hardhat-based build with no published build artifact SHA or reproducibility declaration. Bytecode reproducibility cannot be independently confirmed. Not confirmed non-reproducible but no public verification hash exists. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant Chainlink CCIP used for EVM cross-chain transfers includes inherent CCIP rate-limiting at the OnRamp level. Spiko's own chain-level pause is full-stop (not rate-limited). CCIP rate-limiter is a third-party positive mitigant but not a Spiko-controlled per-chain flow control. Starknet and Stellar cross-chain mechanisms are separate and do not benefit from CCIP rate-limiting.

RD-F-138 green Hot-patch deploys without timelock (last 30 days) No upgrades identified in the last 30 days. Last EVM commit 2026-03-03 (~74 days before profile date). No hot-patch deploy evidence in last 30 days. Note: since no timelock exists, any future upgrade would by definition be hot-patch.

RD-F-140 green Fix-merged-but-not-deployed gap No known vulnerability with merged fix awaiting deployment identified. Halborn findings all resolved per audit page (100% remediated). Trail of Bits findings addressed with no public contrary evidence.

RD-F-141 green Test-mode parameters in deploy Constructor args use production addresses (Permission Manager at 0x344278af; ERC2771Forwarder at 0x42DB5A5A). No test-mode oracle or infinite-allowance patterns identified in ABI or available source.

RD-F-143 green Reinitializable implementation (no _disableInitializers) PermissionManager implementation (0xd3f5f152) confirmed calls _disableInitializers() in constructor via Etherscan bytecode analysis. Token implementation (0x15EA0EC4) uses OZ v5.4.0 Initializable which calls _disableInitializers() in implementation constructors by default. No contrary evidence found.

RD-F-144 green CREATE2 factory permits same-address redeploy No CREATE2 factory usage identified. Spiko uses standard CREATE deployment via Hardhat. No CREATE2 factory scripts found.

RD-F-146 green New contract deploys in last 30 days Last EVM GitHub commit 2026-03-03 (~74 days before assessment). No new contract deployments identified in trailing 30 days. Stellar and Starknet activity level unknown but no recent upgrade evidence found.

RD-F-168 green Stale-approval exposure on deprecated router No deprecated routers. Spiko uses permissioned allowlist system limiting approval surface to KYC-verified addresses. No stale approval risk from deprecated routers identified.

Cross-chain & bridge Green 0 12 of 12

RD-F-148 gray Bridge validator count (M) CCIP uses DON-based threshold signature consensus + RMN (Risk Management Network) for Merkle root blessing. DON node count for Spiko-specific CCIP lanes is not publicly disclosed. Chainlink RMN node count not public per lane. This is a Chainlink infrastructure-level question, not assessable at protocol tier without Chainlink internal documentation. RD-F-149 gray Bridge validator threshold (k-of-M) CCIP uses OCR3-based threshold consensus (not a simple k-of-M multisig). Threshold parameters per Spiko CCIP lane are not publicly disclosed. RMN blessing threshold (cumulative weight) is an internal Chainlink configuration. Not controllable by Spiko. RD-F-150 gray Bridge validator co-hosting CCIP node operators include institutional-grade operators (T-Systems, Swisscom, LinkPool, etc.). Co-hosting specifics not publicly disclosed per lane. Chainlink design explicitly separates DON and RMN node operators ('no overlap'). Cannot assess further at OSINT tier. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) [STAR CRITICAL] TAXONOMY MISMATCH — Chainlink CCIP does NOT use ecrecover for message validation. CCIP uses DON Merkle root commitment + RMN blessing + Merkle proof verification in OffRamp. No direct ecrecover call chain exists. F151 (Wormhole-class ecrecover zero-address check) was designed for validator-signer bridges that verify individual ECDSA signatures; CCIP uses OCR3 threshold signatures + Merkle proofs. The critical pattern targeted by F151 is structurally absent from CCIP's architecture. Not_applicable (taxonomy mismatch, explicitly documented). RD-F-155 gray Bridge validator-set rotation recency CCIP DON and RMN node sets are managed by Chainlink Labs. Rotation recency per Spiko-specific lanes not publicly disclosed. Spiko does not control CCIP validator rotation. RD-F-156 gray Bridge uses same key custody for >30% validators CCIP node operators include institutional-grade operators. Custody specifics per lane not disclosed. Chainlink design explicitly separates DON and RMN operators. Cannot assess co-custody at OSINT tier. RD-F-157 gray Bridge TVL per validator ratio CCIP is shared infrastructure across many protocols. Spiko TVL on CCIP lanes (~$1.2B across EVM chains) is a fraction of total CCIP-secured value. Per-protocol TVL/validator ratio is not a meaningful metric for shared bridge infrastructure. Individual lane validator counts not public. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) NOT APPLICABLE — Spiko uses Chainlink CCIP, not LayerZero OFT. F179 is explicitly scoped to LayerZero OFT adapter integrations. Spiko has no LayerZero OFT adapter. Data cache layerzero.present: false. DVN concept (LayerZero-specific Decentralized Verifier Network) does not apply to CCIP architecture.

RD-F-147 green Protocol has bridge surface Yes — Chainlink CCIP is used for cross-chain EVM token transfers (Ethereum, Arbitrum, Polygon, Base, Etherlink) per public blog post. Profile flags has_bridge_surface: true. Stellar and Starknet cross-chain mechanisms undocumented.

RD-F-152 green Bridge binds message to srcChainId CCIP messages include sourceChainSelector as part of the message header. OffRamp enforces per-chain separation via sourceChainSelector — one CommitStore per source-chain per destination-chain (per-lane architecture). Messages from chain A cannot be replayed on chain B. Chain binding is a core CCIP architectural property.

RD-F-153 green Bridge tracks nonce-consumed mapping CCIP OffRamp implements sequence-based nonce tracking via INonceManager.incrementInboundNonce(). Nonce 0 allows out-of-order execution; non-zero nonces enforce in-order delivery and replay prevention. Replay attacks via nonce reuse are blocked.

RD-F-154 green Default bytes32(0) acceptable as valid root [STAR CRITICAL] CCIP OffRamp.sol explicitly guards against zero-root acceptance: 'if (merkleRoot == bytes32(0)) revert InvalidRoot();' — the Nomad class vulnerability (default zero value accepted as valid root) is explicitly mitigated in CCIP's implementation. Score: green.

Threat intelligence & recon Green 13 8 of 8

RD-F-158 yellow Known-threat-actor cluster has touched protocol No confirmed Lazarus/DPRK wallet interaction with Spiko contracts identified in public sources. However: (1) $1.217B TVL in yield-bearing T-bill tokens is a high-value reconnaissance target; (2) Lazarus has demonstrated KYC bypass via false identity (Drift Apr 2026); (3) redemption flows represent liquid exit channels for stolen capital. Per §15 U4: passive venue use by DPRK attacker != team contamination; this is Cat 11 threat intelligence, not Cat 7 contamination. KYC whitelist provides friction but not complete barrier. Yellow reflects target-profile risk without positive evidence of current interaction. Requires curated TI feed for live monitoring. RD-F-161 yellow Protocol-impersonator domain registered (typosquat) spiko.io registered 2023-10-02 (registration date of official domain, not impersonator). F161 measures whether a typosquat/impersonator domain has been registered within the past 90 days. No impersonator domain identified in web search or public sources. WHOIS monitoring infrastructure (DomainTools, DNSTwister) required for systematic coverage — not accessible via public WebFetch. Spiko's $1.22B TVL gives it meaningful brand recognition as a typosquat target. Yellow rather than green: absence of positive impersonator domain evidence is not same as confirmed absence — monitoring gap acknowledged. F161 registration-date-to-assessment-date delta (official domain): 956 days — domain is well-established, reducing confusion risk slightly vs a newly-launched protocol. RD-F-159 n/a Attacker wallet pre-strike probe (low-gas failing txs) v1-deferred per T-09 §3.3. Requires mempool + threat-actor cluster feed not available at v1 public-OSINT tier. No positive mempool probe signal identified. RD-F-164 gray Leaked credential on paste/sentry site No public paste-site or credential-dump reference to Spiko infra keys found in web search. github.security_md_present: false means SECURITY.md is absent; no flagged secrets in public GitHub repo (spiko-tech/contracts is public). Systematic credential-dump monitoring requires proprietary feed (HaveIBeenPwned business API, Flare.io, CyberSixGill) not accessible via public WebFetch. Scored gray: external API blocked, not N/A. RD-F-165 n/a Protocol social channel has scam-coordinator flag Spiko has no identified Discord or Telegram community channel (confirmed in profile §9 — searched spiko.io footer, GitHub, social links with no Discord/Telegram found). The social-channel admin scam-coordinator signal requires an active community channel to monitor. Signal substrate absent.

RD-F-160 green GitHub malicious-dependency incident touching protocol deps OZ v5.4.0 is the current stable EVM dependency; no GHSA advisory flags it as malicious. Starknet uses Cairo/Scarb ecosystem with no flagged malicious release in the trailing 90-day window. Stellar uses Rust/Cargo dependencies from Halborn-audited stellar-contracts repo (audited 2025-09). Last EVM GitHub commit 2026-03-03 with no supply-chain incident in surrounding timeframe. No malicious dependency release identified.

RD-F-162 green Known-exploit-template selector deployed by any address No known exploit-template selector-pattern for Spiko's custom Permission Manager architecture deployed by any address in available public sources. Spiko's contracts use a purpose-built permission-manager with bitmask group membership — not a Compound/Aave-fork template. No exploit-template DB entry exists for this specific architecture pattern.

RD-F-163 green Avg attacker reconnaissance time for peer-class protocols No active reconnaissance activity identified targeting Spiko. USPD 78-day reconnaissance baseline from T-01: attacker-labeled wallets show 30-90 day reconnaissance windows before strike. RWA-class specific: Drift Apr 2026 involved 6-month reconnaissance. Spiko profile §10 confirms zero incidents in 23-month live history. No test-transaction patterns from known attacker addresses. Clean baseline — no current reconnaissance signal.

Tooling / compiler / AI Green 0 5 of 5

RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation All three codebases are original implementations with no audited upstream to compare against. No EVM clone pattern (not Aave/Compound/UniV3 fork). Factor requires an audited upstream for comparison - not applicable.

RD-F-170 green Solc version used (known-bug versions flagged) EVM deployed bytecode uses Solidity v0.8.24 (Etherscan confirmed: v0.8.24+commit.e11b9ed9). Hardhat config default is 0.8.27, EVM target cancun, viaIR=false. Neither 0.8.24 nor 0.8.27 is on the known-bug list. TransientStorageClearingHelperCollision affects 0.8.28-0.8.33 only - not applicable. Cairo and Soroban not Solidity-compiled.

RD-F-172 green Repo shows AI-tool co-authorship in critical files No AI-tool co-authorship metadata found in reviewed commits. EVM commit history (Token.sol, Oracle.sol, Minter.sol, Jun-2023 to Mar-2026) shows human authors: adam-hotait, fondation451, oscarwroche, Amxx, antoinemch. No Co-authored-by GitHub Copilot or ChatGPT trailers visible. Starknet and Stellar similarly show fondation451 and oscarwroche without AI co-author markers.

RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure of AI-generated code in security-critical paths found. tech.spiko.io describes architecture without AI-generation disclosures. GitHub README and Arbitrum STEP-2 application make no AI-generated code disclosures.

RD-F-174 green Dependency tree uses EOL Solidity version EVM: Solidity 0.8.24 deployed / 0.8.27 build config - both on current supported 0.8.x track, not EOL. Cairo: current Scarb/Starknet Foundry toolchain. Soroban: Rust edition 2021 with soroban-sdk 22.0.8 (current supported). No EOL language or compiler versions detected.

Response & disclosure hygiene Red 50 4 of 4

RD-F-175 red Disclosure channel exists No public security-disclosure channel found. Immunefi returns 404 for /bug-bounty/spiko/. Bugcrowd and HackerOne searches find no Spiko program. Data-cache bug_bounty.platform: null and max_payout_usd: null. No SECURITY.md in the spiko-tech/contracts GitHub repository (confirmed by direct fetch returning 404; data-cache github.security_md_present: false). No security@ email found in spiko.io footer or docs.spiko.io. Profile §9 explicitly flagged this gap. For a $1.22B TVS protocol across seven chains and three codebases, the absence of any structured security-disclosure channel is a material gap. RD-F-176 red Disclosure SLA public No published acknowledgment-time SLA found. No mention of 72-hour ack window, 90-day disclosure deadline, or coordinated-disclosure timeline in any public Spiko documentation (docs.spiko.io, tech.spiko.io, GitHub, or blog). Follows directly from F175: if no disclosure channel exists, no SLA can be published. Consistent with circle-usyc finding where F176 was also red.

RD-F-177 green Prior known-ignored disclosure No prior incidents in the record; therefore no ignored-disclosure scenario can have occurred. Searched post-mortems (none exist), rekt.news (no Spiko entries), hacksdatabase (0 hits). Green here means 'no evidence of this failure mode' rather than 'process verified good' — the distinction is noted. If a disclosure had been made and ignored, it would have been documented in one of the searched sources given the profile of the protocol.

RD-F-178 green CVE/GHSA advisory issued against protocol No CVE, GHSA, or equivalent public advisory found for Spiko smart contracts. No CVE in NVD for 'spiko'. No GHSA advisory under spiko-tech GitHub organization. No public security advisory on any platform found as of 2026-05-16. Clean record is the expected outcome given zero confirmed incidents.

rubric_version v1.7.0 graded_at 2026-05-15 22:52:15 factors 184 protocol spiko