Skip to Content
DocumentationSecurity AuditMethodology

Security Audit Methodology

Welsh Street preformed the initial security audit with Claude Sonnet 4.5. After completed unit testing and line by line code descriptions, each contract was reviewed by the Claude model, line by line and presented below.

Contracts Analyzed

Each per-contract security audit follows a consistent structure:

  • Description — Contract purpose and architectural role within the protocol.
  • Findings — Issues identified with severity ratings, plus a checklist table scoring each of the 10 audit criteria.
  • Recommendations — Suggested changes or confirmation that no changes are needed.
  • Contract Comments — Full contract source annotated line-by-line with security assessments inline as Clarity comments.
ContractPurpose
credit-controller.clarCREDIT-token transfer controller and reward updates
credit-token.clarLP token (SIP-010)
emission-controller.clarToken emission schedule
street-controller.clarSTREET token minting controller
street-market.clarDEX / AMM
street-nft.clarNFT collection
street-rewards.clarLP reward distribution
street-token.clarNative token with emissions
welsh-faucet.clarTestnet faucet

Excluded: welshcorgicoin.clar — pre-existing mainnet contract, cannot be modified.

Test Coverage

All 9 contracts have 100% function and error coverage (79 functions, 35 error codes, 85 test files). Full breakdown available in the testing report.

Audit Checklist

Each contract is evaluated against:

  1. Access Control — Admin gating, contract-caller bypass potential
  2. Input Validation — Bounds checks on public function inputs
  3. Arithmetic — Overflow/underflow, division by zero, rounding
  4. Reentrancy / Call Ordering — State manipulation via interleaved calls
  5. Asset Safety — Transfer/mint/burn guards
  6. Trait Usage — Malicious trait implementation exploits
  7. Authorization Chainstx-sender vs contract-caller correctness
  8. State Consistency — Partial execution leaving inconsistent state
  9. Denial of Service — Functions blocked or made unusable
  10. Upgrade / Migration Risks — Owner transfer safety, irreversible changes

Severity Definitions

SeverityDefinition
CriticalDirect loss of funds or complete protocol compromise
HighSignificant impact requiring immediate fix before deployment
MediumConditional exploit or meaningful governance risk
LowMinor issue, best practice violation, or unlikely scenario
InformationalObservation, optimization, or style suggestion

Design Clarifications

These patterns were reviewed and confirmed as intentional:

  • Overflow — Handled by Clarity runtime
  • Slippage — Omitted on-chain; handled by frontend post-conditions
  • Reentrancy — Safe in Clarity due to atomic transactions
  • Mixed auth patternstx-sender/contract-caller usage varies intentionally per authorization context
  • Contract-only mint/burn — Prevents owner manipulation
  • Hardcoded constants — Immutable by design for predictability
  • Integer precision — Acceptable on-chain precision loss

Conclusion

Strong security foundations. SIP-010 compliant tokens, atomic state management, proper access control separation, and Clarity runtime protections. The medium finding is a deliberate design choice favoring immutability over flexibility.

Per-Contract Reports

Last updated on