Implement a cryptographic nonce manager with replay protection and bounded memory

[Lakes41]

Difficulty: Advanced
Type: Feature
Recommended labels (if available in this repo): security, backend, consistency, advanced

Background

GuildPass will eventually perform signed operations where one-time challenges or nonces are useful for preventing replay. Before any specific wallet-signature or authentication flow exists, Core can establish a reusable nonce lifecycle primitive.

This issue introduces an in-memory nonce manager with explicit issuance, consumption and expiration semantics.

Problem

A nonce that can be reused defeats replay protection. At the same time, an in-memory nonce store that never removes expired records can grow without bound.

Core needs deterministic one-time-use semantics with secure nonce generation and bounded state.

Expected Outcome

Implement a framework-independent nonce manager that securely generates opaque nonces, tracks their validity and guarantees that a valid nonce can be consumed at most once.

Suggested Implementation

The module should:

• generate nonces using Node cryptographic randomness;
• support configurable nonce byte length;
• encode nonces using a URL-safe format;
• associate each nonce with an expiry time;
• provide explicit issue, validate and consume operations;
• ensure consume is atomic within the in-memory implementation;
• distinguish unknown, expired, already-consumed and valid nonces;
• prevent a consumed nonce from becoming valid again;
• clean up expired state;
• enforce a configurable maximum number of retained records or otherwise prevent unbounded memory growth;
• allow time to be injected or abstracted for deterministic tests;
• avoid logging raw nonces unnecessarily;
• remain independent of wallet or session infrastructure.

Acceptance Criteria

• Issued nonces are generated from cryptographically secure randomness.
• Generated nonces have sufficient configurable entropy.
• A newly issued nonce validates successfully before expiry.
• A consumed nonce cannot be consumed a second time.
• Expired nonces are rejected.
• Unknown nonces are rejected.
• Concurrent consume attempts for the same nonce result in at most one successful consumption.
• Expired records are cleaned up or bounded.
• Memory growth is explicitly constrained.
• Unit tests cover issuance, expiry, replay and concurrent consumption.
• Tests use controllable time rather than long sleeps where possible.
• pnpm typecheck passes.
• pnpm build passes.
• pnpm test passes.
• No wallet-signature, authentication, Redis or database functionality is introduced.

Likely Affected Files/Directories

packages/nonce-manager/ or equivalent isolated package
unit tests

Independence Requirement

This issue must be independently implementable from the current main branch and must not rely on wallet authentication, Redis or any other campaign contribution.

[Okorie2000-code]

Hi Maintainer, I’ve reviewed the issue and the scope is clear. I’m ready to implement it and deliver a clean PR within 10hrs. Kindly assign it to me.

[OmniZlatoon]

If I can have just one of your issues sir.... I garantuee you best code practices and quality , ensuring proper documentation of implemented work.