Contract audit trail fix

[blockchainrafik]

Security & data-integrity fixes: auth randomness, wallet uniqueness, pause/unpause audit events

This PR bundles four related fixes found during a review pass over the auth flow, the Soroban contract, and the Prisma schema. Each is small and independent, but grouped here since they touch adjacent code and were found in the same pass.

Closes #701
Closes #702
Closes #703
Closes #700

---

1. generateChallenge() used Math.random() — not cryptographically secure

Closes #701

Problem

const randomBytes = Buffer.from(
  Array.from({ length: 16 }, () => Math.floor(Math.random() * 256))
).toString('hex');

Math.random() in Node.js is backed by V8's XorShift128+ PRNG — fast, but not cryptographically secure. Given enough observed outputs its internal state can be recovered, after which future outputs become predictable. generateChallenge() is called from the public POST /auth/challenge endpoint, so an attacker can observe a stream of challenges and predict — or reconstruct — future nonces, potentially pre-generating valid challenges before they're issued.

Fix

import { randomBytes } from "node:crypto";

export function generateChallenge(walletAddress: string): string {
  const timestamp = Date.now();
  const randomHex = randomBytes(16).toString("hex");
  return `novasupport:${walletAddress}:${timestamp}:${randomHex}`;
}

(Local variable renamed to randomHex to avoid shadowing the imported randomBytes function.)

Testing

• Verified the output format is unchanged: novasupport:{wallet}:{timestamp}:{32-char hex nonce}.
• TODO: add a test asserting consecutive calls never repeat a nonce and that the nonce is valid 32-char hex.

Follow-up (out of scope)

No visible TTL/expiry enforcement on challenges in auth.ts itself — confirm this is enforced elsewhere (e.g. AuthChallenge.expiresAt in the schema) so a captured challenge+signature can't be replayed indefinitely.

---

2. Profile.walletAddress had no @unique constraint — duplicate wallet claims possible

Closes #702

Problem

walletAddress String

Wallet address is the root identity for authentication. Nothing prevented two Profile rows from sharing the same walletAddress, so auth lookups by wallet could resolve non-deterministically. An attacker registering a second profile with a victim's wallet address could intercept that victim's webhook deliveries and milestone notifications.

Fix

walletAddress String @unique

Brings walletAddress in line with every other identity field on Profile (username, email, emailVerificationToken are all already @unique), and matches AuthChallenge.walletAddress, which was already @unique.

Migration

A bare ADD CONSTRAINT UNIQUE fails outright if duplicates already exist in production. migration.sql instead:

1. Ranks any duplicate walletAddress rows by createdAt, treating the oldest as canonical.
2. Renames conflicting rows with a ::dup-N suffix to unblock the constraint, without deciding which profile is "legitimate."
3. Adds the unique index.
4. Leaves commented SQL for a manual post-deploy pass to find ::dup-N rows, contact affected owners, and re-verify wallet ownership via signature before resolving.

No automatic deletion or nulling — walletAddress is required, and a wrong automated call could lock out a legitimate user.

-- run before deploy to size the cleanup
SELECT "walletAddress", COUNT(*), array_agg(id ORDER BY "createdAt")
FROM "Profile"
GROUP BY "walletAddress"
HAVING COUNT(*) > 1;

Testing

• Confirmed no other model joins on Profile.walletAddress, so this is a purely additive constraint.
• TODO: add a test asserting a second Profile created with an already-claimed walletAddress is rejected.
• TODO: run the duplicate-detection query against a staging snapshot before merging.

Follow-up (out of scope)

Confirm whether the auth lookup in app.ts uses findFirst or findUnique for walletAddress. Both work correctly once the constraint exists, but findUnique better expresses the new invariant.

---

3. Duplicate AcceptedAsset rows from concurrent PATCH requests

**Closes #700 **

Problem

AcceptedAsset had no constraint preventing the same (profileId, code, issuer) combination from being inserted more than once. Concurrent PATCH requests against a profile's accepted-assets endpoint could race and insert duplicate rows for the same asset.

Fix

@@unique([profileId, code, issuer])

Testing

• TODO: add a test issuing two concurrent inserts for the same (profileId, code, issuer) and asserting only one succeeds.

---

4. pause() / unpause() emit no on-chain audit events

**Closes #704 **

Problem

pause() and unpause() flip the contract's Paused flag but never emit an event, unlike support() and withdraw() which both publish one. There's no on-chain record of when the contract was paused/unpaused or which admin triggered it, breaking off-chain monitoring and post-incident analysis.

Fix

// pause()
e.events().publish((symbol_short!("pause"), admin), e.ledger().timestamp());

// unpause()
e.events().publish((symbol_short!("unpause"), admin), e.ledger().timestamp());

Testing

• Existing support_fails_when_contract_is_paused and support_succeeds_after_unpause tests pass unchanged.
• TODO: assert on e.events().all() in a pause/unpause test to verify the emitted admin address and timestamp.

Follow-up (out of scope)

initialize() has the same gap — no event emitted when Admin/Paused are first set. Suggest a follow-up PR for an init event.

---

Summary of changed files

• auth.ts — crypto-secure nonce generation
• schema.prisma — walletAddress @unique, AcceptedAsset composite unique constraint
• migration.sql — non-destructive dedup + unique index for walletAddress
• lib.rs (Soroban contract) — pause/unpause events

[drips-wave]

@blockchainrafik Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits