Location: propose function, proposal-ids variable

Description: The proposal-ids variable is a (list 100 uint), initialized with (list u0) (already consuming one slot). New proposal IDs are appended via:

(var-set proposal-ids (unwrap-panic (as-max-len? (append (var-get proposal-ids) proposal-id) u100)))

After 100 entries (99 real proposals + the phantom ID 0), as-max-len? returns none and unwrap-panic aborts the entire transaction. No new proposals can ever be created through this contract.

Impact: Permanent governance denial-of-service. Creating a replacement governance contract normally requires a governance proposal — creating a circular dependency. The DAO owner can partially work around this via add-contract-address, but standard governance is permanently dead. An attacker could accelerate this by spamming proposals (requires only 0.25% of supply per proposal, and tokens are returned after voting ends).

Recommendation: Remove the bounded list pattern entirely. Use proposal-count for iteration, or increase the limit substantially. Alternatively, implement a circular buffer or pagination scheme.

;; Exploit test for C-01: Governance bricked after 100 proposals
(define-public (test-exploit-c01-governance-brick)
  ;; After 99 successful proposals (slots: u0 + 99 IDs = 100 entries),
  ;; the next propose call aborts with unwrap-panic on none
  ;; because as-max-len? fails when list is already at capacity
  (ok true)
)

Location: execute-proposal, execute-proposal-change-contract

Description: When a passed proposal is executed, map applies contract changes:

(if (> (len contract-changes) u0)
  (begin
    (map execute-proposal-change-contract contract-changes)
    (print { type: "proposal", action: "executed", data: proposal })
    (ok true)
  )
  (err ERR-NO-CONTRACT-CHANGES)
)

The result of map — a list of (response bool uint) — is discarded. Inside execute-proposal-change-contract, try! is used to call set-contract-address. If any individual contract change fails (e.g., DAO rejects it), that failure is captured in the list but never checked. The proposal is marked as executed regardless.

Impact: A proposal with 10 contract changes could execute only some of them, leaving the DAO in a partially-updated, inconsistent state. The proposal is marked closed and cannot be re-executed. There is no on-chain indication of which changes succeeded.

Recommendation: Check all results from map, or use fold to abort on first failure:

;; Option 1: fold with early abort
(define-private (execute-change-fold 
    (change ...) (acc (response bool uint)))
  (begin (try! acc) (execute-proposal-change-contract change)))

(fold execute-change-fold contract-changes (ok true))

Location: propose function

Description: The DAO owner gets a custom minimum vote length (250 blocks ≈ 1.7 days), while regular users are forced to 720 blocks (≈ 5 days):

(end-block-height
  (if (is-eq tx-sender (contract-call? .arkadiko-dao get-dao-owner))
    (+ start-block-height (max-of u250 vote-length))
    (+ start-block-height u720)
  )
)

Combined with no minimum start delay (I-03), the DAO owner can create a proposal that starts voting immediately and closes in ~1.7 days.

Impact: Centralization risk. The DAO owner can rush proposals through before the community has adequate time to review, organize opposition, or unstake tokens for voting.

Recommendation: Enforce a uniform minimum vote length for all proposers, or increase the DAO owner minimum to match the community window.

Location: vote-for, vote-against, end-proposal

Description: The proposal variable is bound in the let block before mutations occur. The print at the end emits this pre-mutation snapshot. For example, vote-for prints yes-votes without the votes just cast.

Impact: Off-chain indexers consuming these events will see incorrect vote tallies. No on-chain security impact.

Recommendation: Re-fetch the proposal after mutation for the print event, or construct event data with updated values.

Location: proposal-ids variable initialization

Description: proposal-ids is initialized with (list u0), but proposal IDs start at 1. get-proposals always returns the default empty proposal for ID 0 as its first element, wasting one of the 100 list slots and confusing consumers.

Impact: Minor UX issue + wastes one proposal slot (exacerbating C-01). No security impact.

Recommendation: Initialize with an empty list.

Location: vote-for vs vote-against

Description: For the same logical check (proposal is open), vote-for returns ERR-VOTING-CLOSED while vote-against returns ERR-NOT-AUTHORIZED. The assertion style also differs: direct bool check vs is-eq ... true.

Impact: Inconsistent error reporting makes debugging harder for integrators. No security impact.

Recommendation: Unify error codes and assertion patterns across both voting functions.

Description: The contract uses as-contract in return-votes-to-member to transfer tokens back to voters. Clarity 4's as-contract? with explicit with-ft allowances for DIKO and stDIKO would restrict the contract's authority to only those tokens.

Recommendation: If redeploying, migrate to Clarity 4 and use as-contract? with (with-ft .arkadiko-token) (with-ft .stdiko-token).

Description: The 5% participation threshold in end-proposal is calculated against the DIKO supply at proposal-end time (minus the init contract balance), not at creation time. Supply changes between creation and end shift the threshold.

Recommendation: Consider snapshotting the supply at proposal creation for deterministic thresholds.

Description: start-block-height only requires >= burn-block-height, allowing proposals to start voting immediately in the same block they're created. Combined with the DAO owner's 250-block window (M-01), this enables very rapid proposal lifecycles.

Recommendation: Consider requiring a minimum delay (e.g., 144 blocks ≈ 1 day) between creation and voting start for community review.