|
| 1 | +# AIBTC DAO Platform Consistency Analysis |
| 2 | + |
| 3 | +## 1. Error Code Definitions |
| 4 | + |
| 5 | +### Inconsistency: |
| 6 | +- Some contracts use `ERR_` prefix (most common) |
| 7 | +- Some use full words like `INPUT_ERROR` (in `aibtc-onchain-messaging.clar`) |
| 8 | +- Some use shorter forms like `ERR_UNAUTHORIZED` vs `ERR_NOT_DAO_OR_EXTENSION` |
| 9 | + |
| 10 | +### Recommendation: |
| 11 | +Standardize all error codes with the `ERR_` prefix followed by a descriptive name in uppercase with underscores. |
| 12 | + |
| 13 | +## 2. Print Event Notifications |
| 14 | + |
| 15 | +### Inconsistency: |
| 16 | +- Most contracts use a structured format with `notification` and `payload` fields |
| 17 | +- The payload structure varies between contracts |
| 18 | +- Some print events include more fields than others for similar actions |
| 19 | + |
| 20 | +### Recommendation: |
| 21 | +Standardize the print event structure across all contracts: |
| 22 | +``` |
| 23 | +(print { |
| 24 | + notification: "[action-name]", |
| 25 | + payload: { |
| 26 | + // Consistent set of fields based on action type |
| 27 | + } |
| 28 | +}) |
| 29 | +``` |
| 30 | + |
| 31 | +## 3. Function Naming Conventions |
| 32 | + |
| 33 | +### Inconsistency: |
| 34 | +- Some functions use hyphenated names (`set-payment-address`) |
| 35 | +- Similar functions have different names across contracts (e.g., `toggle-resource` vs `allow-asset`) |
| 36 | +- Some functions have inconsistent verb usage (e.g., `get-` vs direct noun) |
| 37 | + |
| 38 | +### Recommendation: |
| 39 | +Standardize function naming with consistent verbs: |
| 40 | +- Use `get-` prefix for all read-only functions |
| 41 | +- Use `set-` prefix for state-changing functions that update a single value |
| 42 | +- Use consistent action verbs (`add-`, `remove-`, `toggle-`, etc.) |
| 43 | + |
| 44 | +## 4. Variable Naming |
| 45 | + |
| 46 | +### Inconsistency: |
| 47 | +- Some variables use camelCase (`lastWithdrawalBlock`) |
| 48 | +- Others use kebab-case in function parameters |
| 49 | +- Inconsistent abbreviations (e.g., `pmt` vs `payment`) |
| 50 | + |
| 51 | +### Recommendation: |
| 52 | +Standardize on kebab-case for all function parameters and consistent abbreviations throughout. |
| 53 | + |
| 54 | +## 5. Constants Naming |
| 55 | + |
| 56 | +### Inconsistency: |
| 57 | +- Some constants use `CFG_` prefix (`CFG_PAYMENT_TOKEN`) |
| 58 | +- Others use descriptive names without prefixes (`VOTING_DELAY`) |
| 59 | +- Some use `SELF` while others use `TREASURY` for contract principal |
| 60 | + |
| 61 | +### Recommendation: |
| 62 | +Standardize constant naming: |
| 63 | +- Use all uppercase with underscores |
| 64 | +- Use consistent prefixes for similar types of constants |
| 65 | +- Standardize on `SELF` for the contract principal reference |
| 66 | + |
| 67 | +## 6. Data Structure Consistency |
| 68 | + |
| 69 | +### Inconsistency: |
| 70 | +- Different naming conventions for similar data structures across contracts |
| 71 | +- Inconsistent field names in similar data structures |
| 72 | +- Varying approaches to optional fields |
| 73 | + |
| 74 | +### Recommendation: |
| 75 | +Create consistent data structure templates for common concepts (proposals, resources, etc.) and use them across all contracts. |
| 76 | + |
| 77 | +## 7. Specific Inconsistencies Found |
| 78 | + |
| 79 | +### Payment Processor Contracts |
| 80 | +- Three nearly identical implementations (`aibtc-payment-processor-dao.clar`, `aibtc-payment-processor-stx.clar`, `aibtc-payment-processor-sbtc.clar`) with minor differences |
| 81 | +- Inconsistent handling of payment methods |
| 82 | + |
| 83 | +### Timed Vault Contracts |
| 84 | +- Similar inconsistencies between `aibtc-timed-vault-dao.clar`, `aibtc-timed-vault-stx.clar`, and `aibtc-timed-vault-sbtc.clar` |
| 85 | +- Different default values for similar concepts |
| 86 | + |
| 87 | +### Proposal Contracts |
| 88 | +- Inconsistent approach between `aibtc-action-proposals-v2.clar` and `aibtc-core-proposals-v2.clar` |
| 89 | +- Different voting parameter names and structures |
| 90 | + |
| 91 | +### Treasury Contract |
| 92 | +- Inconsistent approach to asset management compared to other resource management |
| 93 | + |
| 94 | +## 8. Documentation Style |
| 95 | + |
| 96 | +### Inconsistency: |
| 97 | +- Some contracts have detailed headers with version, title, summary |
| 98 | +- Others have minimal or no documentation |
| 99 | +- Inconsistent inline commenting style |
| 100 | + |
| 101 | +### Recommendation: |
| 102 | +Standardize documentation with: |
| 103 | +- Consistent header format for all contracts |
| 104 | +- Standard sections for traits, constants, data vars, etc. |
| 105 | +- Consistent inline commenting style |
| 106 | + |
| 107 | +## 9. Error Handling Patterns |
| 108 | + |
| 109 | +### Inconsistency: |
| 110 | +- Some functions use `try!` for authorization checks |
| 111 | +- Others use `asserts!` directly |
| 112 | +- Inconsistent error propagation |
| 113 | + |
| 114 | +### Recommendation: |
| 115 | +Standardize error handling patterns: |
| 116 | +- Use `try!` consistently for authorization and external calls |
| 117 | +- Use `asserts!` for validation checks |
| 118 | +- Consistent approach to error propagation |
| 119 | + |
| 120 | +## 10. Authorization Checks |
| 121 | + |
| 122 | +### Inconsistency: |
| 123 | +- Some contracts check `is-dao-or-extension` at the beginning |
| 124 | +- Others perform checks later in the function |
| 125 | +- Inconsistent implementation of the check itself |
| 126 | + |
| 127 | +### Recommendation: |
| 128 | +Standardize authorization checks: |
| 129 | +- Always perform them at the beginning of functions |
| 130 | +- Use consistent implementation across all contracts |
0 commit comments