SP2ZNGJ85ENDY6QRHQ5P2D4FXKGZWCKTB2T0Z55KS.dao-traits-v4
Audited: 2026-02-25 · Clarity version: pre-Clarity 4 · Confidence: High
dao-traits-v4 is a trait-definition-only contract from StackerDAO Labs. It defines 10 traits for a modular DAO framework: SIP-010 fungible tokens, proposals, governance tokens, extensions, NFTs, liquid fungible tokens, CDK/EDK energy-tap interfaces, an extended FT trait with mint/burn, and a share-fee-to trait.
This contract contains zero executable code — no functions, no state, no assets. It is purely a collection of define-trait declarations that other contracts implement.
Source: On-chain (Hiro Explorer) · Hiro API
Architecture: The contract serves as a shared interface registry for StackerDAO's modular DAO system. Contracts implementing these traits can be composed via contract-call? with trait parameters, enabling a pluggable DAO architecture where proposals, extensions, governance tokens, and fee-sharing components are interchangeable.
| Metric | Score | Weight | Weighted |
|---|---|---|---|
| Financial risk | 0 | 3 | 0 |
| Deployment likelihood | 3 | 2 | 6 |
| Code complexity | 0 | 2 | 0 |
| User exposure | 2 | 1.5 | 3 |
| Novelty | 1 | 1.5 | 1.5 |
| Raw Score | 1.05 | ||
| Clarity version penalty (pre-Clarity 4) | -0.50 | ||
| Final Score | 0.55 ✗ | ||
Note: This contract scores below the 1.8 audit threshold. It is included as a reference audit for the StackerDAO trait ecosystem. Trait-only contracts have no attack surface of their own — findings are purely informational design observations.
dmg- prefixed function namesDescription: The governance token trait defines functions with dmg- prefixes (e.g., dmg-get-balance, dmg-transfer, dmg-lock). "DMG" likely refers to an internal token name. This namespace prefix couples the trait to a specific implementation's naming convention rather than being generic.
(define-trait governance-token-trait
(
(dmg-get-balance (principal) (response uint uint))
(dmg-has-percentage-balance (principal uint) (response bool uint))
(dmg-transfer (uint principal principal) (response bool uint))
(dmg-lock (uint principal) (response bool uint))
(dmg-unlock (uint principal) (response bool uint))
(dmg-get-locked (principal) (response uint uint))
(dmg-mint (uint principal) (response bool uint))
(dmg-burn (uint principal) (response bool uint))
)
)Impact: Any contract implementing this trait must use the dmg- prefix, even if its governance token has a different name. This reduces trait reusability across projects. A contract named "VOTE" still needs dmg-get-balance.
Recommendation: For a future v5, consider generic names: gov-get-balance, gov-transfer, gov-lock, etc. This would make the trait more broadly adoptable.
sip010-ft-trait duplicates the canonical SIP-010 traitDescription: This contract defines its own sip010-ft-trait that is functionally identical to the canonical SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait. In Clarity, trait identity is based on the defining contract — so a contract implementing this local copy does not satisfy the canonical SIP-010 trait, and vice versa.
Impact: Contracts implementing StackerDAO's sip010-ft-trait cannot be used interchangeably with contracts expecting the canonical SIP-010 trait reference. This creates a parallel trait ecosystem that fragments interoperability. Implementors must implement both traits or choose one.
Recommendation: Reference the canonical trait via use-trait instead of redefining it. For functions that accept SIP-010 tokens, use the canonical trait principal. This is a common pattern in Stacks — the canonical trait exists specifically to avoid this fragmentation.
nft-trait duplicates the canonical SIP-009 NFT traitDescription: Similar to I-02, the contract defines its own nft-trait that mirrors the canonical SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait. Same interoperability concern applies.
Impact: NFT contracts implementing this local trait are not recognized by tools and marketplaces that check for the canonical SIP-009 trait.
Recommendation: Use the canonical NFT trait reference.
governance-token-trait transfer lacks memo parameterDescription: The dmg-transfer function signature is (uint principal principal) → (response bool uint), omitting the optional memo buffer present in SIP-010. The standard SIP-010 transfer defined in the same contract includes (optional (buff 34)).
;; SIP-010 in same contract — has memo:
(transfer (uint principal principal (optional (buff 34))) (response bool uint))
;; Governance token trait — no memo:
(dmg-transfer (uint principal principal) (response bool uint))Impact: Governance token transfers cannot carry memo data for exchange attribution or record-keeping. This is a minor interoperability gap — exchanges and bridges commonly rely on transfer memos.
Recommendation: Add (optional (buff 34)) parameter to dmg-transfer for consistency with SIP-010.
For reference, the 10 traits defined in this contract:
| Trait | Functions | Purpose |
|---|---|---|
sip010-ft-trait | 7 | SIP-010 fungible token (duplicate of canonical) |
proposal-trait | 1 | DAO proposal — single execute entry point |
governance-token-trait | 8 | Governance token with lock/unlock/mint/burn |
extension-trait | 1 | DAO extension callback interface |
nft-trait | 4 | SIP-009 NFT (duplicate of canonical) |
liquid-ft-trait | 3 | FT with deflation mechanism |
cdk-trait | 1 | Charisma dungeon key — energy tap |
edk-trait | 1 | Extended dungeon key — energy tap with CDK param |
ft-plus-trait | 9 | SIP-010 + mint/burn (superset) |
share-fee-to-trait | 1 | Fee distribution receiver |
This is a zero-risk trait-only contract. It contains no executable code, holds no assets, and maintains no state. The findings are purely design observations about naming conventions and trait duplication. The most actionable recommendation is to reference canonical SIP-010 and SIP-009 traits rather than redefining them, to improve cross-ecosystem interoperability.