StacksMint — Token Factory & Registry

C-1 Registry Has No Ownership Verification — Full Impersonation Possible

Contract: stacksmint.clar · register-token

The register-token function accepts any token-contract principal and arbitrary metadata with zero on-chain verification:

(define-public (register-token
    (token-contract principal)
    (name (string-ascii 32))
    (symbol (string-ascii 10))
    (decimals uint)
    (total-supply uint)
    (token-uri (optional (string-utf8 256))))
  (let ((caller tx-sender) ...)
    ;; No verification that caller deployed token-contract
    ;; No contract-call? to verify metadata matches
    ;; owner is set to tx-sender, not the contract's deployer
    (map-set token-registry token-contract
      { ... owner: caller ... })))

Attack vectors:

• Impersonation: Register sBTC's contract principal with fake metadata (e.g., name: "sBTC", symbol: "sBTC", but with attacker as owner)
• Front-running: Watch mempool for deploy-contract txs, immediately register the new contract principal — the real deployer gets ERR-ALREADY-REGISTERED
• Metadata fraud: Register a legitimate contract with inflated supply or misleading name/symbol

The registry cannot call (contract-call? token-contract get-name) to verify because the token principal is a runtime parameter, not a known contract. This is a fundamental design limitation — the registry architecture cannot provide trustworthy data.

H-1 Registration Fee Is Zero Despite Anti-Spam Claims

Contract: stacksmint.clar

The README advertises "STX registration fee (anti-spam)" as a feature. The code says otherwise:

;; Registration is free -- no STX fee required
(define-constant REGISTRATION-FEE u0)

With zero cost and no verification, an attacker can flood the registry with thousands of fake entries in a single block. The total-fees-collected data var increments by zero — pure dead code. The registry becomes trivially unusable as a discovery tool.

H-2 Front-Running Token Registration — Permanent Griefing

Contract: stacksmint.clar

Since register-token sets the owner field to tx-sender (not the token contract's actual deployer), and registration is free, a front-running attack is trivial:

1. Attacker monitors mempool for deploy-contract transactions
2. Attacker submits register-token with the victim's contract principal
3. Victim's later register-token call fails with ERR-ALREADY-REGISTERED (u200)
4. Only the attacker (fake owner) can call update-token-uri

There is no admin override, no dispute mechanism, and no deregistration function. The legitimate creator is permanently locked out of their registry entry.

M-1 tx-sender Auth Limits Composability

Contract: token-template.clar · transfer

(asserts! (is-eq tx-sender sender) ERR-NOT-TOKEN-OWNER)

Using tx-sender instead of contract-caller means no smart contract can transfer tokens on behalf of a user. DEXes, vaults, and any intermediary contract calling transfer will fail. This is SIP-010 compliant but breaks DeFi composability. The standard allows either approach — this is the safer but more restrictive choice.

M-2 Unguarded Burn — Any Holder Can Deflate Supply

Contract: token-template.clar · burn

(define-public (burn (amount uint) (sender principal))
  (begin
    (asserts! (is-eq tx-sender sender) ERR-NOT-TOKEN-OWNER)
    (asserts! (> amount u0) ERR-INVALID-AMOUNT)
    (ft-burn? stacksmint-token amount sender)))

Any holder can burn their own tokens at will. Unlike minting (which has a mintable flag), there is no burnable control. For tokens where supply determines governance weight or economic value, unchecked burning by individual holders can skew distribution. Template users may not realize this is enabled by default.

M-3 Globally Writable Counter Utility — No Access Control

Contract: token-template.clar · increment / decrement

(define-public (increment)
  (begin
    (var-set utility-counter (+ (var-get utility-counter) u1))
    (ok (var-get utility-counter))))

The counter is a public function with no access control, sharing a single utility-counter across all callers. Anyone can increment/decrement it at any time. If any frontend or integration relies on this value, it's trivially manipulable. This pollutes the contract's ABI with a function that has no practical production use.

L-1 Registry Owner Cannot Be Transferred

(define-constant registry-owner tx-sender) — immutable. No ownership transfer function exists. Currently the owner has no admin functions, but if fee collection or entry management is added later, the owner is permanently fixed to the deploy-time principal.

L-2 Token Owner Cannot Be Transferred

Same issue in token-template.clar: (define-constant contract-owner tx-sender). If the deployer's key is lost, mint control is permanently inaccessible.

L-3 No Token Deregistration or Metadata Correction

Registry entries are permanent. update-token-uri exists, but name, symbol, decimals, and total-supply are immutable after registration. Typos, malicious registrations, and stale data have no correction path.

I-1 Unlimited Minting When Enabled

When the mintable flag is set to true, the owner can mint unlimited tokens with no maximum supply cap. This is a known trust assumption but should be prominently documented for token holders evaluating the contract.