+ {address
+ ? "Your member wallet is connected. Your archive access appears below."
+ : "A private archive of all RaidGuild Discord server channels. Connect your member wallet to enter."}
+
+ );
+}
+
+export function WalletControl({
+ showWhenDisconnected = true,
+ variant = "header",
+}: WalletControlProps) {
+ return (
+
+ {({
+ account,
+ chain,
+ openAccountModal,
+ openChainModal,
+ openConnectModal,
+ authenticationStatus,
+ mounted,
+ }) => {
+ const ready = mounted && authenticationStatus !== "loading";
+ const connected = Boolean(
+ ready &&
+ account &&
+ chain &&
+ (!authenticationStatus || authenticationStatus === "authenticated"),
+ );
+
+ return (
+
+ );
+ }}
+
+ );
+}
diff --git a/app/utils/fuzzy.ts b/app/utils/fuzzy.ts
new file mode 100644
index 0000000..8f9c6fc
--- /dev/null
+++ b/app/utils/fuzzy.ts
@@ -0,0 +1,42 @@
+const WORD_SEPARATORS = new Set([" ", "-", "_", "/", "."]);
+
+export function fuzzyScore(query: string, candidate: string) {
+ const needle = query.trim().toLowerCase();
+ const haystack = candidate.toLowerCase();
+
+ if (!needle) return 0;
+
+ const exactIndex = haystack.indexOf(needle);
+ if (exactIndex !== -1) {
+ return 1000 - exactIndex * 2 - (haystack.length - needle.length) * 0.01;
+ }
+
+ let score = 0;
+ let searchFrom = 0;
+ let previousMatchEnd = -1;
+
+ for (const character of needle) {
+ const matchIndex = haystack.indexOf(character, searchFrom);
+ if (matchIndex === -1) return null;
+
+ score += 10;
+
+ if (
+ matchIndex === 0 ||
+ WORD_SEPARATORS.has(haystack[matchIndex - 1] || "")
+ ) {
+ score += 8;
+ }
+
+ if (matchIndex === previousMatchEnd) {
+ score += 12;
+ } else if (previousMatchEnd >= 0) {
+ score -= Math.min(matchIndex - previousMatchEnd, 8);
+ }
+
+ previousMatchEnd = matchIndex + character.length;
+ searchFrom = previousMatchEnd;
+ }
+
+ return score - haystack.length * 0.01;
+}
diff --git a/docs/pr-review-workflow.md b/docs/pr-review-workflow.md
index 978730d..8bf4faa 100644
--- a/docs/pr-review-workflow.md
+++ b/docs/pr-review-workflow.md
@@ -1,70 +1,78 @@
-# Pull Request Review Workflow
+# PR Review Comment Workflow
-Use this workflow when inspecting or addressing GitHub pull-request feedback.
+Use this workflow when an agent is asked to handle GitHub PR review feedback.
-## Safety And Authority
+## Safety
-- Never expose credentials, private data, production records, local machine
- paths, or infrastructure details in chat, logs, commits, tests, or GitHub
- replies.
-- Prefer repository-scoped credentials with the minimum required permissions.
-- Keep authentication in approved local tooling, environment variables, or
- ignored files.
-- Do not stage, commit, push, post GitHub comments, dismiss reviews, or resolve
+- Do not paste tokens, secrets, private data, or real user data into chat, logs,
+ commits, tests, or GitHub replies.
+- Prefer repository-scoped credentials with the minimum permissions needed.
+- Use the connected GitHub app and repository-scoped credentials as directed by
+ `AGENTS.md`; keep credentials in approved environment variables or ignored
+ local files.
+- Do not stage, commit, push, comment, dismiss reviews, or resolve GitHub
threads without explicit user approval.
## Flow
-1. Fetch all unresolved review threads.
+1. Fetch all unresolved review threads first.
- Preserve thread IDs, file paths, line anchors, resolution state, and
- outdated state.
- - Do not rely only on flat comment lists when thread state matters.
+ whether comments are outdated.
+ - Avoid relying only on flat comment lists when thread state matters.
2. Summarize the review map before editing.
- List each actionable thread.
- - Explain what it claims, whether it appears accurate, and the intended
- response.
- - Separate duplicates, outdated comments, informational notes, and ambiguous
- requests from actionable findings.
+ - For each thread, state what it claims, whether it appears accurate, and
+ the intended action.
+ - Separate duplicate, outdated, informational, or ambiguous comments from
+ actionable ones.
-3. Validate each finding against the code and approved scope.
- - Inspect the relevant implementation and surrounding behavior.
+3. Validate each comment against the code.
+ - Inspect the relevant code and surrounding behavior.
- Do not assume the reviewer is correct.
- - If a finding is inaccurate, preserve the evidence needed for a concise
- reply.
+ - If the comment is inaccurate, record the reason for the eventual reply.
-4. Fix approved findings locally.
- - Keep each change traceable to its review thread.
- - Prefer cohesive fixes and verification over one commit per comment.
- - Pause when feedback conflicts with product intent, another comment, the
- approved scope, or a safety boundary.
+4. Fix valid comments locally.
+ - Keep changes traceable to the review thread.
+ - Prefer cohesive local fixes over one commit or push per comment.
+ - If a comment conflicts with product intent or another comment, pause and
+ explain the tradeoff.
-5. Verify the selected fixes.
- - Run focused checks for narrow changes.
+5. Verify after the selected fixes.
+ - Run the smallest useful tests for narrow changes.
- Run broader checks for shared behavior, wallet authentication, membership
- authorization, S3 access, external APIs, or user flows.
- - Record exactly which checks passed and which could not run.
+ authorization, S3 access, signed URLs, external APIs, or UI flow.
+ - Record exactly which checks passed or could not be run.
-6. Report local results before publication.
+6. For PR-sized fixes, complete the independent-review gate from
+ `docs/session-workflow.md` after automated verification and before staging
+ or describing the changes as ready to merge.
+
+7. Summarize local results to the user.
- List fixed threads.
- - List intentionally unchanged or partially addressed threads with reasons.
- - List changed files and verification evidence.
- - Ask before staging, committing, pushing, or replying on GitHub.
+ - List intentionally unchanged threads and why.
+ - List files changed and verification commands.
+ - Ask before staging, committing, pushing, or posting GitHub replies.
-7. Reply only after approval and publication.
- - When code changed, reply after the fix is pushed.
- - Include the commit SHA when available.
- - State what changed and what verification supports it, or why no change was
- made.
- - Leave resolution to the user unless they explicitly delegate it.
+8. Reply to GitHub threads only after approval.
+ - Reply after code is pushed when a code fix was made.
+ - Include the commit SHA or short SHA that contains the fix when one is
+ available.
+ - Keep replies concise and specific: what changed, what check supports it,
+ or why it was left unchanged.
+ - Leave thread resolution to the user unless they explicitly ask the agent
+ to resolve threads.
## Reply Style
-Good replies are brief and evidenced:
+Good replies:
- `Addressed in abc1234 by validating the request body before creating a signed URL. Verified with pnpm lint and pnpm build.`
-- `Leaving this unchanged because the approved behavior requires the current membership gate; the route still verifies the signed message server-side.`
-- `Partially addressed: the UI now prevents the invalid action, while the server guard remains the source of truth.`
+- `Leaving this unchanged: the route intentionally verifies membership server-side because the wallet UI check is not an authorization boundary.`
+- `Partially addressed: the UI now blocks the invalid action, while the API route retains the server-side guard.`
+
+Avoid:
-Avoid vague replies such as `Fixed`, unnecessary implementation narration,
-sensitive values, and resolving threads without permission.
+- exposing secrets, wallet signatures, signed URLs, or private user data;
+- vague replies like `Fixed`;
+- resolving threads without the user's permission.
diff --git a/docs/session-workflow.md b/docs/session-workflow.md
index f4f6b6e..860738e 100644
--- a/docs/session-workflow.md
+++ b/docs/session-workflow.md
@@ -1,180 +1,224 @@
# Session Workflow
-Work may continue across different Codex sessions, branches, and pull requests,
-so each session should rebuild enough context before implementation begins.
-
-## Sources Of Truth
-
-- `AGENTS.md` defines repository-wide agent instructions.
-- `package.json`, `pnpm-lock.yaml`, and `pnpm-workspace.yaml` define package
- manager, scripts, dependency policy, and approved package build scripts.
-- `README.md` is starter documentation unless it has been deliberately updated.
-- `app/` and `components/` define current product behavior.
-- Older attachments, handoffs, brainstorms, and chat history are context, not
- authority, unless the user explicitly promotes a decision into tracked docs or
- code.
-
-## Start Substantial Sessions This Way
-
-Before editing files for anything larger than a tiny mechanical change:
-
-1. Read `AGENTS.md`, this workflow, and `docs/model-effort-workflow.md`.
-2. Recommend the lowest adequate effort level for the current task when the
- task is broad, risky, or ambiguous.
-3. Confirm the current branch and worktree state.
-4. Identify the directories likely to change and read every applicable nested
- `AGENTS.md` from the repository root down to those directories.
-5. Confirm the current unit of work with the user when scope is not obvious.
-6. Debrief the work:
- - intended user-visible outcome;
- - explicit non-goals and stopping point;
- - technical approach and decisions still open;
- - expected files, services, dependencies, and environment variables;
- - verification commands and manual QA;
- - commit and PR boundary;
- - proportional review gate.
-7. Break the work into sequential tasks when the change is more than one
- coherent edit.
-8. Propose the intended commit sequence when the work naturally divides into
- multiple reviewable commits.
-9. Wait for explicit approval before broadening scope, installing new
- dependencies, committing, pushing, or taking GitHub actions.
-
-Repository-wide workflow files establish the process and approval boundaries.
-Nested guidance may refine instructions for its subtree but may not weaken
-repository-wide scope, privacy, security, approval, or review requirements. Stop
-and resolve conflicting guidance before editing.
-
-## Work Planning Checklist
-
-Before writing non-trivial code, agree on:
-
-- unit goal and acceptance criteria;
-- user-visible outcome;
-- effort recommendation when useful;
-- technical approach;
-- dependency or service changes;
-- data, storage, and migration effects;
-- environment-variable names without secret values;
-- assets to copy or generate;
-- automated verification and manual QA;
-- commit strategy and PR boundary;
-- review strategy.
-
-Explain and obtain agreement before choosing a new framework, dependency,
-external service, datastore, or foundational pattern.
+The Valhalla work may continue across multiple Codex sessions,
+branches, and pull requests. Rebuild the working context deliberately before
+editing, and keep each change bounded by an agreed outcome.
+
+## Sources of Truth
+
+Use these sources in order:
+
+1. The user's current request, acceptance criteria, and explicit decisions.
+2. The candidate's intended parent or merge base as the implementation
+ baseline; use `main` only when it is the intended parent.
+3. The current repository code, `README.md`, and durable documents in `docs/`.
+4. Reviewed local changes in the active worktree.
+
+Older handoffs, attachments, brainstorms, and chat history are useful context,
+but they are not authoritative when they conflict with the current request or
+repository. Surface conflicts instead of silently choosing one.
+
+## Start Every Session This Way
+
+1. Confirm the repository, current branch, and worktree status. Preserve
+ unrelated user changes.
+2. Read every applicable `AGENTS.md` from the repository root down to the
+ directories likely to change.
+3. For Next.js work, read the relevant installed guide in
+ `node_modules/next/dist/docs/` before editing. This repository may use APIs
+ and conventions that differ from prior Next.js versions.
+4. Read the durable workflow that applies to the task:
+ - `docs/model-effort-workflow.md` for broad, ambiguous, or risky work;
+ - `docs/pr-review-workflow.md` before handling PR review feedback.
+5. Inspect the implementation, tests, configuration examples, and documentation
+ directly related to the request.
+6. Restate the goal, important non-goals, likely files or systems, and proposed
+ verification when the task is broad or ambiguous.
+7. Identify any decision that would materially change product behavior,
+ architecture, dependencies, data, privacy, security, cost, or external
+ state. Ask the user before making that decision.
+8. Break substantial work into sequential tasks and keep the user informed
+ while work is in progress.
+
+Do not require a new planning round for a narrow, already-approved change.
+Proceed with reasonable, reversible assumptions when the repository resolves
+the details and the result remains within the agreed scope.
+
+## Planning Checklist
+
+Before substantial implementation, establish the relevant parts of:
+
+- user-visible outcome and non-goals;
+- technical approach and affected trust boundaries;
+- data, storage, and compatibility requirements;
+- environment variables and secret-handling requirements;
+- external APIs, on-chain reads, membership checks, or storage behavior;
+- dependencies or services that would be added;
+- testing and verification commands;
+- preview and manual-QA expectations;
+- branch, commit, and PR boundary;
+- proportional independent-review strategy.
+
+Explain and obtain agreement before introducing a dependency, service,
+foundational pattern, destructive data change, or material expansion of scope.
## Implementation Rules
-- Keep work within the agreed unit.
-- Do not begin the next unit without a new debrief when scope changes
- materially.
-- Do not install dependencies until their purpose is understood and accepted.
-- Do not start a development server unless the user expects a preview or it is
- required for verification.
-- Preserve `.env` and other ignored local configuration.
+- Keep changes within the agreed feature or fix.
+- Treat the candidate's intended parent or merge base as the reviewed baseline,
+ using `main` only when it is the intended parent, and use a clearly named
+ feature branch before publishing work.
+- Preserve existing and unrelated worktree changes.
+- Keep credentials, signatures, signed URLs, private endpoints, real user data,
+ and internal-only notes out of source, tests, logs, screenshots, and
+ documentation.
+- Keep `.env` and other local secret files ignored. Read only the exact
+ credential needed for an approved workflow, and never print or persist it.
+- Do not install dependencies or agent tooling unless the task requires them
+ and the choice has been agreed.
+- Do not start or expose a development server unless implementation or
+ expected QA requires it.
+- Keep wallet authentication and membership authorization server-validated;
+ client checks may improve the experience but are not an authorization
+ boundary.
+- Keep S3 credentials and signed URL creation server-side.
- Use conventional commit messages.
-- Keep tracked documentation generic: never record credentials, developer
- machine paths, local infrastructure topology, private operational details, or
- real user data.
-- Keep wallet authentication and membership authorization server-validated; UI
- checks may improve experience but must not become the only guard.
-- Keep S3 credentials and signed URL generation server-side.
+- Do not stage, commit, push, open or update a PR, post GitHub replies, resolve
+ review threads, or change shared external state without explicit user
+ approval.
## Verification
-Use the narrowest verification that proves the change, then broaden for shared
-or security-sensitive behavior.
+Verification should be proportional to the change and should exercise failure
+paths as well as success paths.
-Common checks:
+Common checks are:
- `pnpm lint`
- `pnpm build`
+- focused automated tests when the repository defines them
+- `git diff --check`
Notes:
-- This project uses pnpm. The workspace file also stores pnpm settings such as
- approved package build scripts.
-- `pnpm build` may need network access because `next/font/google` fetches
- Titillium Web during the build.
-- If the shell can run `pnpm` but not package binaries, confirm `node` is on
- `PATH` before treating script failures as project failures.
-
-## Review And Closeout
-
-Before declaring work complete or preparing a pull request:
-
-1. Run the agreed verification commands.
-2. Review the diff for correctness, regressions, accessibility,
- maintainability, unnecessary complexity, and scope compliance.
-3. Perform a privacy and security pass:
- - confirm local environment files and secrets are ignored;
- - confirm no credentials, private hostnames, local absolute paths, private
- URLs, internal notes, or real user data are tracked;
- - confirm public UI copy does not expose implementation details;
- - confirm authentication, membership checks, storage, signed URLs, and
- external calls are intentional and approved.
-4. Use the proportional review gate below for consequential changes.
-5. Resolve accepted findings and rerun affected verification.
-6. For UI changes, perform user-facing QA when feasible and approved,
- including browser inspection for responsive layout and wallet-related states
- that can be safely exercised.
-7. Summarize what changed, verification and QA evidence, deviations, and
- remaining work.
-8. Keep the PR boundary narrow enough to review comfortably.
-
-Read `docs/pr-review-workflow.md` before opening or updating a pull request, or
-before responding to review feedback.
-
-## Review Gate
-
-Use a fresh review pass after implementation and automated verification are
-complete, but before publication, for consequential changes.
+- This project uses pnpm, and `pnpm-workspace.yaml` also stores pnpm settings.
+- `pnpm build` may need network access when `next/font/google` fetches fonts.
+- If pnpm starts but package binaries report `node: not found`, confirm the
+ shell's Node runtime before diagnosing the repository.
-### Reviewer Count
+Apply additional scrutiny where appropriate:
-- Use one fresh-context, read-only reviewer for a normal commit or PR-sized
- unit when review is warranted.
-- Use two reviewers with distinct specialties when work materially changes
- authentication, authorization, privacy, security, storage, data integrity,
- foundational architecture, or external integrations.
-- Add reviewers only when they have clearly different responsibilities.
+- For UI changes, test the affected wallet and membership states and relevant
+ mobile, tablet, and desktop viewports. Provide a focused manual-QA checklist
+ when visual or interactive judgment is material.
+- For wallet authentication, membership authorization, S3 access, signed URLs,
+ and external APIs, test malformed input, rejection, replay, timeout,
+ unavailable-source, and privacy behavior as applicable.
+- For documentation-only changes, validate links, commands, file names, and
+ repository-specific claims. Do not run unrelated expensive suites solely for
+ ceremony.
+
+Record exactly what passed, what was not run, and why.
+
+## Sequential Commit Gates
+
+When a feature is intentionally split into multiple commits:
+
+1. Implement only the current commit's agreed scope.
+2. Run proportional verification.
+3. Freeze implementation edits and review the exact candidate diff against its
+ intended parent.
+4. Resolve findings and rerun affected checks.
+5. Complete any meaningful manual QA.
+6. Present the scope, evidence, review disposition, and QA disposition to the
+ user.
+7. Wait for explicit approval, stage only the reviewed files, inspect the
+ staged diff, and create the approved commit.
+8. Start the next commit only after the current boundary is complete.
-Useful specialties include:
+If implementation accidentally spans several planned commits, preserve the
+work but reconstruct and review each candidate boundary before describing it
+as sequentially verified.
-- **Technical:** correctness, failure modes, tests, architecture, runtime
- behavior, dependencies, unnecessary complexity, and scope compliance.
-- **Security and privacy:** wallet signatures, authorization, secrets, data
- handling, S3 access, signed URLs, external calls, and trust boundaries.
-- **Experience:** user-visible behavior, accessibility, responsive layout,
- keyboard and touch operation, and control clarity.
+## Independent Review Gate
+
+Run an independent review after a PR-sized implementation and its automated
+verification are complete, but before staging it for publication or declaring
+it ready to merge. Earlier narrow reviews do not replace a final integration
+review when several changes combine into one feature.
+
+### Reviewer Count
+
+- Use one fresh-context, read-only reviewer for a normal PR-sized change.
+- Use two reviewers with distinct specialties when work materially changes
+ wallet authentication, membership authorization, privacy, S3 access, signed
+ URLs, external integrations, or foundational architecture.
+- Add an experience and accessibility reviewer when a change has a substantial
+ user-interface surface.
+- Avoid repeated general reviews that do not add a distinct perspective.
+
+Useful Valhalla review specialties include:
+
+- **Technical:** correctness, failure modes, Next.js behavior, tests, runtime
+ behavior, dependencies, and maintainability.
+- **Security and privacy:** wallet signatures, membership authorization,
+ secrets, S3 access, signed URLs, external calls, and trust boundaries.
+- **Experience and accessibility:** wallet and membership states, responsive
+ layout, keyboard and touch behavior, loading and error states, and control
+ clarity.
### Review Procedure
-1. Finish implementation and its verification.
+1. Finish implementation and run the agreed checks.
2. Freeze implementation edits while reviewers inspect the work.
-3. Give each reviewer the approved goal, acceptance criteria, stopping point,
- relevant docs, and complete diff from the intended base.
-4. Keep reviewers read-only. They report findings but do not edit, commit,
- push, merge, or broaden scope.
-5. Require evidence-based findings with severity, tight file and line
- references when applicable, the violated contract or risk, and a concise
- correction direction. Reviewers explicitly report when no actionable issue
- exists.
-6. Classify findings:
+3. Give reviewers the approved goal, acceptance criteria, non-goals, relevant
+ repository guidance, and the complete diff from the same intended-parent or
+ merge-base baseline used for implementation.
+4. Keep reviewers read-only. They report findings but do not edit files,
+ create commits, broaden scope, or publish anything.
+5. Require evidence-based findings with severity, file and line references,
+ the violated contract or risk, and a concise correction direction.
+6. Classify findings as:
- **P0:** catastrophic or unsafe; blocks acceptance immediately.
- - **P1:** material correctness, security, privacy, or data-loss risk; blocks
- merge.
- - **P2:** important scope, maintainability, testing, accessibility, or
- operational issue; normally fix before merge.
- - **P3:** minor improvement that may be fixed or explicitly deferred.
+ - **P1:** material correctness, security, privacy, or data-loss issue;
+ blocks merge.
+ - **P2:** important maintainability, testing, accessibility, operational,
+ or scope issue; normally fix before merge.
+ - **P3:** minor improvement that may be fixed now or deliberately deferred.
7. Evaluate every finding rather than accepting it automatically.
-8. Apply agreed fixes and rerun affected verification.
-9. Request focused re-review of material fixes and disputed findings.
-10. Report material deferred or unresolved findings to the user and record them
- in durable docs only when approved.
+8. Fix valid findings, rerun affected verification, and request focused
+ re-review for material changes or disputed findings.
+9. Present the final findings, fixes, deferred items, and verification evidence
+ to the user. The user remains the merge authority.
+
+When delegated reviewers are unavailable or not authorized, perform a
+separate fresh-context review pass and disclose that the review was not
+independently delegated.
Independent review supplements rather than replaces automated tests, runtime
-verification, privacy and security checks, and user acceptance. If independent
-agents are unavailable, perform a distinct fresh-context review pass and clearly
-disclose that it was not independently delegated.
+verification, privacy and security checks, and user acceptance.
+
+## Review and Closeout
+
+Before asking to publish work:
+
+1. Run the agreed verification.
+2. Complete meaningful browser or manual QA.
+3. Review correctness, regressions, accessibility, and maintainability.
+4. Review privacy and security:
+ - confirm secret files remain ignored;
+ - confirm the diff contains no credentials, signatures, signed URLs, private
+ endpoints, real user data, or internal-only notes;
+ - confirm public UI and documentation expose only intended information;
+ - confirm wallet authentication, membership checks, storage, signed URLs,
+ and external calls are intentional.
+5. Complete the proportional independent-review gate.
+6. Summarize what changed and any deviation from the agreed approach.
+7. State exactly which checks passed and any that were not run.
+8. List remaining work, deferred findings, deployment notes, and manual-QA
+ status.
+9. Wait for explicit approval before staging, committing, pushing, or creating
+ or updating a PR.
+
+Before opening or updating a PR, or responding to PR review feedback, follow
+`docs/pr-review-workflow.md`.
diff --git a/next.config.js b/next.config.js
index 658404a..f96b93c 100644
--- a/next.config.js
+++ b/next.config.js
@@ -1,4 +1,11 @@
/** @type {import('next').NextConfig} */
-const nextConfig = {};
+const allowedDevOrigins = (process.env.DEV_ALLOWED_ORIGINS || "")
+ .split(",")
+ .map((origin) => origin.trim())
+ .filter(Boolean);
+
+const nextConfig = {
+ allowedDevOrigins,
+};
module.exports = nextConfig;
diff --git a/public/brand/crystal.svg b/public/brand/crystal.svg
new file mode 100644
index 0000000..741b29c
--- /dev/null
+++ b/public/brand/crystal.svg
@@ -0,0 +1,62 @@
+
diff --git a/public/brand/full-m800.svg b/public/brand/full-m800.svg
new file mode 100644
index 0000000..8d458dc
--- /dev/null
+++ b/public/brand/full-m800.svg
@@ -0,0 +1,13 @@
+
diff --git a/public/brand/portal-arch-c.webp b/public/brand/portal-arch-c.webp
new file mode 100644
index 0000000..887f1ad
Binary files /dev/null and b/public/brand/portal-arch-c.webp differ
diff --git a/public/brand/swords.svg b/public/brand/swords.svg
new file mode 100644
index 0000000..9fb29ea
--- /dev/null
+++ b/public/brand/swords.svg
@@ -0,0 +1,3 @@
+
diff --git a/public/brand/symbol-m500.svg b/public/brand/symbol-m500.svg
new file mode 100644
index 0000000..6b8f7cd
--- /dev/null
+++ b/public/brand/symbol-m500.svg
@@ -0,0 +1,3 @@
+
diff --git a/public/fonts/MAZIUSREVIEW20.09-Regular.woff b/public/fonts/MAZIUSREVIEW20.09-Regular.woff
new file mode 100644
index 0000000..5644534
Binary files /dev/null and b/public/fonts/MAZIUSREVIEW20.09-Regular.woff differ
diff --git a/public/fonts/MaziusDisplay-Bold.otf b/public/fonts/MaziusDisplay-Bold.otf
new file mode 100644
index 0000000..581bef7
Binary files /dev/null and b/public/fonts/MaziusDisplay-Bold.otf differ
diff --git a/public/fonts/MaziusDisplay-Extraitalic.otf b/public/fonts/MaziusDisplay-Extraitalic.otf
new file mode 100644
index 0000000..01c9eaf
Binary files /dev/null and b/public/fonts/MaziusDisplay-Extraitalic.otf differ
diff --git a/sample.env b/sample.env
index ec59a5e..3eed097 100644
--- a/sample.env
+++ b/sample.env
@@ -1,10 +1,14 @@
# WalletConnect Project ID
NEXT_PUBLIC_PROJECT_ID='walletconnect-project-id'
+# Additional hostnames allowed to proxy the Next.js development server
+DEV_ALLOWED_ORIGINS='your-development-hostname.example'
+
# JWT Secret - unsure if used
JWT_SECRET='your_jwt_secret_here'
# S3 Configuration
+S3_BUCKET='your-bucket-name-here'
S3_ENDPOINT='your_s3_endpoint_here'
S3_REGION='your_s3_region_here'
S3_KEY='your_access_key_here'