M-01 No Parameter Bounds Validation in set-token

Location: set-token function

Description: The set-token function accepts arbitrary uint values for all parameters with no sanity checks. A DAO owner mistake (or compromise) could set catastrophic values:

• liquidation-ratio: u0 — vaults become unliquidatable regardless of collateral ratio
• max-debt: u0 — effectively freezes new vault creation for that token
• stability-fee: u10000 (100%) — drains vault owners via fees
• vault-min-debt: u0 — enables dust vaults that are uneconomical to liquidate

(define-public (set-token
  (token principal)
  (token-name (string-ascii 12))
  (max-debt uint)          ;; no minimum
  (vault-min-debt uint)    ;; no minimum
  (stability-fee uint)     ;; no maximum
  (liquidation-ratio uint) ;; no minimum — u0 breaks liquidation math
  ...
)
  (begin
    (asserts! (is-eq contract-caller (contract-call? .arkadiko-dao get-dao-owner)) (err ERR_NOT_AUTHORIZED))
    ;; No parameter validation — values go straight to map
    (map-set tokens { token: token } { ... })
    (ok true)
  )
)

Impact: Downstream contracts (vault manager, liquidation engine) consume these parameters directly. Invalid values could brick vault operations, prevent liquidations, or enable undercollateralized minting. The blast radius depends on how the vault manager validates these inputs — if it trusts this registry blindly, the impact is systemic.

Recommendation: Add minimum bounds for critical parameters:

(asserts! (>= liquidation-ratio u10000) (err ERR_INVALID_PARAM))  ;; min 100%
(asserts! (> vault-min-debt u0) (err ERR_INVALID_PARAM))
(asserts! (<= stability-fee u5000) (err ERR_INVALID_PARAM))       ;; max 50%

L-01 Pre-Clarity 4 Contract

Description: Contract does not use Clarity 4 features. However, since this contract has no as-contract calls and performs no token transfers, the practical impact is negligible. The contract cannot benefit from as-contract? with asset allowances because it never moves assets.

Impact: Minimal. Noted for completeness — a Clarity 4 redeployment would gain contract-hash? for verifiability but provides no security improvement for this contract's functionality.

I-01 Centralized DAO Owner Control

Description: All parameter changes route through a single arkadiko-dao get-dao-owner check. This is standard for Arkadiko's architecture and matches the pattern seen across their contract suite. The DAO owner can modify any token's parameters or remove tokens entirely in a single transaction.

Impact: Documented trust assumption. If the DAO owner key is compromised, an attacker could silently modify liquidation ratios to prevent liquidations, then open undercollateralized vaults through a separate contract interaction.

I-02 No Events for Parameter Changes

Description: Neither set-token nor remove-token emit print events. Parameter changes are only visible by polling the contract's map state. Off-chain monitoring systems and governance dashboards cannot subscribe to configuration changes.

Recommendation: Add (print { event: "token-updated", token: token, ... }) to admin functions for off-chain observability.

I-03 Filter Pattern Uses Mutable Shared State

Description: The remove-token function uses a data-var token-to-remove as a closure workaround for the filter builtin, since Clarity's filter only accepts a named function (no closures). This is a well-known Clarity idiom and is safe in the single-transaction context (Clarity has no concurrency). However, the data-var persists after the transaction completes, leaving a stale value.

(define-data-var token-to-remove principal tx-sender)

(define-public (remove-token (token principal))
  (begin
    ...
    (var-set token-to-remove token)
    (var-set token-list (filter is-token-to-remove (var-get token-list)))
    (ok true)
  )
)

(define-read-only (is-token-to-remove (token principal))
  (not (is-eq token (var-get token-to-remove)))
)

Impact: None — the stale value is harmless since token-to-remove is only read during the filter call within the same transaction. Standard Clarity pattern.