Add category column to support server‑side / backend wallet security checks

[pad01g]

• Add category column and description tables
• Assign ConsumerWallet tag to all existing entries (assuming multiple tags for a single entry is allowed in future)

cf. #6

Below are examples of entries that I'm going to add in separate PR once this PR is accepted.

8. Hot Wallet

#	Description	Comment	Attacks/Reports	Category
8.1	Verify that private keys are stored with proper file system permissions (e.g., 600 or 400) or encrypted storage with access controls restricting unauthorized access.	Secure key storage		HotWallet
8.2	Ensure automated balance monitoring is implemented with configurable minimum thresholds for both native tokens and ERC-20 tokens, with immediate alerting when thresholds are breached.	Fund protection		HotWallet
8.3	Verify that transaction processing implements proper nonce management and retry mechanisms to prevent double-spending and transaction conflicts.	Transaction integrity		HotWallet

[matiassequeira]

Hi @pad01g!

Thank you for submitting your PR— looking good at first glance! The only issue is that uploading the categories before the checks for each individual category are included makes it impossible to assess whether a given category is necessary and applicable to the checklist.

I’d suggest submitting everything together in a single PR so all the information is available in one place. Alternatively, you could send one PR per category, making sure to fill in the Category Description section along the way.

[pad01g]

@matiassequeira
Hi, I removed unused category for now. I plan to send one PR per category.

[matiassequeira]

Sounds good! Feel free to add your first category and its issues in this PR, and we can continue that way. Thank you.

[pad01g]

@matiassequeira
I added 10 entries for HotWallet category. Please have a look when you have time.

[matiassequeira]

Hi @pad01g. Will be taking a look at this during the week. Thanks

[matiassequeira]

Hey @pad01g, sorry for the delay. We reviewed the section you proposed and have a few questions and suggestions.

• 8.1, We believe this check should focus towards protecting the private key from being in plaintext in storage at anytime (e.g. to prevent leaks via backups). It currently assumes that private keys are stored in a file.
• 8.3: Would it be possible to split this check between nonce management and retry mechanisms? These are different aspects and implementations to consider.
• 8.7: Under which scenario would this be strictly necessary? Because all this information is present in the blockchain.
• 8.9: Would you please explain this check and how it directly relates to security?

In parallel, we are also preparing more checks that will fit in this category!

[pad01g]

@matiassequeira

Thanks for feedback!

8.1: Rewritten to state that private keys must be encrypted at rest (never stored in plaintext).

8.3: Split into two separate checks—8.3 (nonce management) and 8.11 (retry mechanisms)—since they are distinct concerns.

8.7: Clarified that this item exists for reconciliation, alerting, and auditability, and added rationale explaining why local timestamps/status are needed even though some data is on-chain.

8.9: Based on practical experience, products are often asked to add new currencies/networks later. If the framework isn’t designed for multi-currency from the start, teams tend to ship ad-hoc changes under time and budget pressure, which can weaken controls. While not a direct control, this is a security-motivated architectural recommendation.

[pad01g]

@matiassequeira
Hi, do you have any updates?