Referrals (TimeCurve): on-chain slugs, routing restrictions, CHARM bonuses, leaderboard #43

New issue

Closed

opened 2026-04-22 12:46:13 +00:00 by PlasticDigits · 9 comments

PlasticDigits commented 2026-04-22 12:46:13 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Summary

End-to-end review and implementation of referrals for TimeCurve (and shared Yieldomega infrastructure): documentation, invariants, smart contracts, indexer, frontend, scripts, and agent skills. This issue is the tracking umbrella for all touchpoints.

Product behavior

On-chain referral slug (identity)

• Users register a slug matching [a-zA-Z0-9]+ (alphanumeric only).
• Slug state is authoritative on-chain (not indexer/frontend as source of truth).
• Slugs are transferable between wallets via UX on a dedicated referral page.
• Registration cost: burn 1 CL8Y (exact mechanics TBD in contract design; align with existing burn patterns).

Restricted words / routing (governance)

• Maintain a governance-updatable on-chain mapping (or equivalent) of restricted words reserved for dapp routing (e.g. timecurve, other top-level app segments).
• Purpose: allow clean URLs like yieldomega.com/{slug} while preventing collisions with product routes.

URL capture → persistent referral code (client)

• Any Yieldomega URL may carry the slug:
  • yieldomega.com/{slug}
  • yieldomega.com/timecurve/{slug} (and analogous paths as product routes evolve)
• When a user lands with a referral slug, store it as the referral code in a hard-to-remove (but not impossible) way:
  • localStorage, survives normal sessions; technical users can clear — acceptable.
  • UX/invariants: once “locked in,” treat as stable for the product flow (document edge cases).

TimeCurve purchase incentives (CHARM)

• When buying on TimeCurve with a valid referral:
  • Buyer: +5% CHARM (bonus on the purchase side — define precisely vs. base mint/claim in specs).
  • Referrer: +5% CHARM (to the referral account tied to the slug).
• Self-refers: banned on-chain or in authoritative validation (define invariant).
• Multi-account: allowed; acknowledge Sybil — “technical users” gain less from referrals; document tradeoffs.

UX requirements (TimeCurve)

• Anywhere in the TimeCurve dapp flow where the user buys CHARM, surface:
  • Their current referral code (if any / locked state).
  • Whether they are receiving the +5% buyer bonus or not (clear affirmative/negative states).

Leaderboard (on-chain linked list + indexer)

• Metric: total CHARM earned by the referral account (slug owner / referral identity — define accounting in spec).
• Structure: linked list on-chain for ordering.
• Inserts: dapp suggests an insertion index/position; contract/indexer validates.
• Reconciliation: if the suggested position is wrong, contract walks the list up to 20 adjacent nodes to repair ordering / placement (exact algorithm to be specified).
• Indexer: tracks on-chain leaderboard state and serves read models to the frontend (no authoritative leaderboard state off-chain).

Deliverables / review checklist

Use this list to scope MRs; check off as completed.

Documentation

• Product/spec: referral lifecycle, URL rules, lock semantics, CL8Y burn, +5% / +5% split, self-refer ban.
• docs/testing/invariants-and-business-logic.md (or equivalent): new invariants and test map entries for referrals + TimeCurve purchase paths.
• Routing / reserved words: governance operations and collision rules.
• Leaderboard: linked-list invariants, suggestion protocol, ±20 hop repair, indexer expectations.

Smart contracts

• Slug registry (mint/transfer/burn CL8Y registration), restricted-word set, referral validation hooks for TimeCurve purchases.
• CHARM distribution changes for buyer + referrer bonuses (+5% / +5%).
• Leaderboard linked-list contract + insertion/repair logic (max 20 steps).
• Tests (unit/integration) per docs/testing/strategy.md.

Indexer

• Schema / processors for slug state, restricted words, referral events, leaderboard list.
• APIs or subgraph-style queries for frontend (leaderboard, “my referral,” earnings totals).

Frontend (Yieldomega + TimeCurve)

• Referral page: register, transfer slug, show link previews / copy link.
• URL middleware or router: parse {slug} vs. product routes using on-chain restricted set (or cached mirror with clear staleness rules).
• localStorage referral capture + lock UX; edge cases when user clears storage.
• TimeCurve purchase surfaces: referral code + +5% eligibility UI.
• Leaderboard UI fed by indexer.

Scripts & tooling

• Deployment / governance scripts for restricted words and any admin roles.
• Local/dev fixtures for referral scenarios.

Agent skills / rules (if applicable)

• Update .cursor/skills/ or docs under docs/agents/ so future agents treat on-chain state as authoritative and reference new invariants.

Open questions (to resolve in design)

1. Exact definition of “+5% CHARM” relative to existing TimeCurve mint/fee mechanics (basis points, rounding, caps).
2. Whether restricted words are a prefix trie, exact match set, or per-path; how subdomains fit.
3. Leaderboard sort key tie-breakers and whether list is globally sorted or segmented.
4. Slug length bounds and uniqueness rules (case sensitivity — recommend one canonical form on-chain).

Related

• TimeCurve product docs and docs/product/primitives.md where CHARM flows are defined.
• Keep game rules and fund flows on-chain; indexer/frontend remain derived layers per repo guardrails.

## Summary End-to-end review and implementation of **referrals for TimeCurve** (and shared Yieldomega infrastructure): documentation, invariants, smart contracts, indexer, frontend, scripts, and agent skills. This issue is the **tracking umbrella** for all touchpoints. ## Product behavior ### On-chain referral slug (identity) - Users register a **slug** matching `[a-zA-Z0-9]+` (alphanumeric only). - Slug state is **authoritative on-chain** (not indexer/frontend as source of truth). - Slugs are **transferable between wallets** via UX on a dedicated **referral page**. - **Registration cost:** burn **1 CL8Y** (exact mechanics TBD in contract design; align with existing burn patterns). ### Restricted words / routing (governance) - Maintain a **governance-updatable on-chain mapping** (or equivalent) of **restricted words** reserved for **dapp routing** (e.g. `timecurve`, other top-level app segments). - Purpose: allow clean URLs like `yieldomega.com/{slug}` while preventing collisions with product routes. ### URL capture → persistent referral code (client) - Any Yieldomega URL may carry the slug: - `yieldomega.com/{slug}` - `yieldomega.com/timecurve/{slug}` (and analogous paths as product routes evolve) - When a user lands with a referral slug, store it as the **referral code** in a **hard-to-remove** (but not impossible) way: - **localStorage**, survives normal sessions; **technical users can clear** — acceptable. - UX/invariants: once “locked in,” treat as stable for the product flow (document edge cases). ### TimeCurve purchase incentives (CHARM) - When buying on TimeCurve with a valid referral: - **Buyer:** **+5% CHARM** (bonus on the purchase side — define precisely vs. base mint/claim in specs). - **Referrer:** **+5% CHARM** (to the referral account tied to the slug). - **Self-refers:** **banned** on-chain or in authoritative validation (define invariant). - **Multi-account:** allowed; acknowledge Sybil — “technical users” gain less from referrals; document tradeoffs. ### UX requirements (TimeCurve) - Anywhere in the TimeCurve dapp flow where the user **buys CHARM**, surface: - Their **current referral code** (if any / locked state). - Whether they are **receiving the +5% buyer bonus** or not (clear affirmative/negative states). ### Leaderboard (on-chain linked list + indexer) - **Metric:** **total CHARM earned** by the **referral account** (slug owner / referral identity — define accounting in spec). - **Structure:** **linked list** on-chain for ordering. - **Inserts:** dapp **suggests** an insertion index/position; contract/indexer validates. - **Reconciliation:** if the suggested position is wrong, contract walks the list **up to 20** adjacent nodes to **repair** ordering / placement (exact algorithm to be specified). - **Indexer:** tracks on-chain leaderboard state and **serves read models** to the frontend (no authoritative leaderboard state off-chain). ## Deliverables / review checklist Use this list to scope MRs; check off as completed. ### Documentation - [ ] Product/spec: referral lifecycle, URL rules, lock semantics, CL8Y burn, +5% / +5% split, self-refer ban. - [ ] `docs/testing/invariants-and-business-logic.md` (or equivalent): new invariants and test map entries for referrals + TimeCurve purchase paths. - [ ] Routing / reserved words: governance operations and collision rules. - [ ] Leaderboard: linked-list invariants, suggestion protocol, ±20 hop repair, indexer expectations. ### Smart contracts - [ ] Slug registry (mint/transfer/burn CL8Y registration), restricted-word set, referral validation hooks for TimeCurve purchases. - [ ] CHARM distribution changes for buyer + referrer bonuses (+5% / +5%). - [ ] Leaderboard linked-list contract + insertion/repair logic (max 20 steps). - [ ] Tests (unit/integration) per `docs/testing/strategy.md`. ### Indexer - [ ] Schema / processors for slug state, restricted words, referral events, leaderboard list. - [ ] APIs or subgraph-style queries for frontend (leaderboard, “my referral,” earnings totals). ### Frontend (Yieldomega + TimeCurve) - [ ] Referral page: register, transfer slug, show link previews / copy link. - [ ] URL middleware or router: parse `{slug}` vs. product routes using on-chain restricted set (or cached mirror with clear staleness rules). - [ ] localStorage referral capture + lock UX; edge cases when user clears storage. - [ ] TimeCurve purchase surfaces: referral code + +5% eligibility UI. - [ ] Leaderboard UI fed by indexer. ### Scripts & tooling - [ ] Deployment / governance scripts for restricted words and any admin roles. - [ ] Local/dev fixtures for referral scenarios. ### Agent skills / rules (if applicable) - [ ] Update `.cursor/skills/` or docs under `docs/agents/` so future agents treat on-chain state as authoritative and reference new invariants. ## Open questions (to resolve in design) 1. Exact definition of “+5% CHARM” relative to existing TimeCurve mint/fee mechanics (basis points, rounding, caps). 2. Whether restricted words are a prefix trie, exact match set, or per-path; how subdomains fit. 3. Leaderboard sort key tie-breakers and whether list is globally sorted or segmented. 4. Slug length bounds and uniqueness rules (case sensitivity — recommend one canonical form on-chain). ## Related - TimeCurve product docs and `docs/product/primitives.md` where CHARM flows are defined. - Keep game rules and fund flows **on-chain**; indexer/frontend remain derived layers per repo guardrails.

PlasticDigits commented 2026-04-22 13:48:33 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in commit 7ce23157f0

mentioned in commit 7ce23157f0e5acd28181c1b205884263a64a8310

PlasticDigits commented 2026-04-22 13:48:43 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Issue 43 — implementation note (pushed to `main` @ 7ce2315)

Summary: Shipped a focused slice of the referral/TimeCurve umbrella: client capture + routing, a real Referrals surface (on-theme), and a safe TimeCurve sub-route branch so arena / protocol cannot be lost behind a single dynamic timecurve/:x param.

What changed

• Path capture (client): `?ref=` still works; it overrides a path code when both are present. Path capture is only for `/timecurve/{code}` (3–16, `a–z0–9` after normalize). A bare `/{code}` route was not added: a `/:segment` catch-all was colliding with post-launch routes like `/home` in the router, so the product doc now recommends `?ref=` and `/timecurve/{code}` until a collision-free top-level design exists (e.g. prefix route or on-chain reserved set + static routes).
• TimeCurve routes: `TimeCurveBranchPage` dispatches `timecurve/arena`, `timecurve/protocol`, and all other second segments to the simple sale view, with lazy chunks preserved.
• `/referrals` UI: `ReferralRegisterSection` — reads registry from `VITE_REFERRAL_REGISTRY_ADDRESS` or from TimeCurve’s `referralRegistry`, shows live `REFERRAL_EACH_BPS` when TimeCurve is configured, `CL8Y` approve + `registerCode`, and copyable links. Plaintext is stored in `localStorage` on successful register (chain only stores the hash). On-chain transfer is still not in the contract; the page says so.
• Tests/docs: `referralPathCapture` Vitest; Playwright `referral-path` (localStorage after `/timecurve/abc12`); `e2e/timecurve` protocol step accepts Configuration missing when `VITE_TIMECURVE_ADDRESS` is unset (local), matching CI which sets a stub address. Product + invariant map updated.

Note on issue body vs on-chain spec: The umbrella issue text mentions +5% CHARM per side; `TimeCurve.REFERRAL_EACH_BPS` and `docs/product/referrals.md` are the canonical 10% (1000 bps) each until governance changes the constant.

@brouie — can you run through this checklist on staging or a build from `7ce2315`?

• Open `/timecurve/abc12` (or any valid 3–16 code): URL stays, localStorage key `yieldomega.ref.v1` has `code: "abc12"`.
• `/?ref=abc12` still works; with both path + query, query wins.
• `/timecurve/arena` and `/timecurve/protocol` still show Arena and Protocol (not the simple sale view).
• `/referrals` — hero, sections, and register panel match the arcade shell; with wallet + `VITE_*` addresses, Register approves CL8Y and calls `registerCode` (or capture revert if no faucet).
• On post-launch build (`VITE_LAUNCH_TIMESTAMP` in the past), `/home` is still HomePage and `/` is TimeCurve simple (we removed the `/:slug` route that could steal `/home`).

CI: `unit-tests` will run `npm run build` + `test:e2e` with the workflow’s VITE env; local e2e can still be sensitive to a stale preview on :4173 or a mismatched post-launch build.

## Issue 43 — implementation note (pushed to \`main\` @ 7ce2315) **Summary:** Shipped a focused slice of the referral/TimeCurve umbrella: client capture + routing, a real **Referrals** surface (on-theme), and a safe **TimeCurve** sub-route branch so `arena` / `protocol` cannot be lost behind a single dynamic `timecurve/:x` param. **What changed** - **Path capture (client):** \`?ref=\` still works; it **overrides** a path code when both are present. Path capture is **only** for \`/timecurve/{code}\` (3–16, \`a–z0–9\` after normalize). A bare \`/{code}\` route was **not** added: a \`/:segment\` catch-all was colliding with post-launch routes like \`/home\` in the router, so the product doc now recommends \`?ref=\` and \`/timecurve/{code}\` until a collision-free top-level design exists (e.g. prefix route or on-chain reserved set + static routes). - **TimeCurve routes:** \`TimeCurveBranchPage\` dispatches \`timecurve/arena\`, \`timecurve/protocol\`, and all other second segments to the **simple** sale view, with **lazy** chunks preserved. - **\`/referrals\` UI:** \`ReferralRegisterSection\` — reads registry from \`VITE_REFERRAL_REGISTRY_ADDRESS\` or from TimeCurve’s \`referralRegistry\`, shows live \`REFERRAL_EACH_BPS\` when TimeCurve is configured, \`CL8Y\` **approve** + \`registerCode\`, and copyable links. Plaintext is stored in \`localStorage\` on successful register (chain only stores the hash). **On-chain transfer** is still not in the contract; the page says so. - **Tests/docs:** \`referralPathCapture\` **Vitest**; **Playwright** \`referral-path\` (localStorage after \`/timecurve/abc12\`); \`e2e/timecurve\` protocol step accepts **Configuration missing** when \`VITE_TIMECURVE_ADDRESS\` is unset (local), matching CI which sets a stub address. Product + invariant map updated. **Note on issue body vs on-chain spec:** The umbrella issue text mentions **+5%** CHARM per side; \`TimeCurve.REFERRAL_EACH_BPS\` and \`docs/product/referrals.md\` are the canonical **10% (1000 bps) each** until governance changes the constant. @brouie — can you run through this checklist on **staging or a build from \`7ce2315\`**? - [ ] Open \`/timecurve/abc12\` (or any valid 3–16 code): URL stays, **localStorage** key \`yieldomega.ref.v1\` has \`code: \"abc12\"\`. - [ ] \`/?ref=abc12\` still works; with **both** path + query, **query** wins. - [ ] \`/timecurve/arena\` and \`/timecurve/protocol\` still show **Arena** and **Protocol** (not the simple sale view). - [ ] \`/referrals\` — hero, sections, and register panel match the **arcade** shell; with wallet + \`VITE_*\` addresses, **Register** approves CL8Y and calls \`registerCode\` (or capture revert if no faucet). - [ ] On **post-launch** build (\`VITE_LAUNCH_TIMESTAMP\` in the past), \`/home\` is still **HomePage** and \`/\` is **TimeCurve simple** (we removed the \`/:slug\` route that could steal \`/home\`). **CI:** \`unit-tests\` will run \`npm run build\` + \`test:e2e\` with the workflow’s VITE env; local e2e can still be sensitive to a **stale** preview on :4173 or a **mismatched** post-launch build.

PlasticDigits commented 2026-04-22 13:57:17 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Follow-up — referral CHARM rate (5% each side)

Completed a consistency pass so per-side referral CHARM matches 5% everywhere that documents or displays this split (not FeeRouter / Rabbit 10% or WarBow 10% steal mechanics).

• On-chain: TimeCurve.REFERRAL_EACH_BPS is 500 (5% of charmWad each to buyer + referrer as charmWeight).
• Docs / params: docs/product/referrals.md, contracts/PARAMETERS.md updated.
• Arena (TimeCurvePage): copy uses REFERRAL_EACH_BPS via formatBpsAsPercent with fallback 5.00% if the read is unavailable.
• Tests: TimeCurveReferral.t.sol asserts refEach from REFERRAL_EACH_BPS().

Merged to main and pushed (0f400e0). Note: already-deployed TimeCurve instances keep their prior constant until redeployed or otherwise upgraded—verify live REFERRAL_EACH_BPS on the target contract.

**Follow-up — referral CHARM rate (5% each side)** Completed a consistency pass so **per-side referral CHARM** matches **5%** everywhere that documents or displays this split (not FeeRouter / Rabbit **10%** or WarBow **10%** steal mechanics). - **On-chain:** `TimeCurve.REFERRAL_EACH_BPS` is **500** (5% of `charmWad` each to buyer + referrer as `charmWeight`). - **Docs / params:** `docs/product/referrals.md`, `contracts/PARAMETERS.md` updated. - **Arena (`TimeCurvePage`):** copy uses **`REFERRAL_EACH_BPS`** via `formatBpsAsPercent` with fallback **5.00%** if the read is unavailable. - **Tests:** `TimeCurveReferral.t.sol` asserts `refEach` from `REFERRAL_EACH_BPS()`. Merged to `main` and pushed (`0f400e0`). **Note:** already-deployed TimeCurve instances keep their prior constant until redeployed or otherwise upgraded—verify live `REFERRAL_EACH_BPS` on the target contract.

Brouie commented 2026-04-23 05:58:26 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

@PlasticDigits #43 verification on 7ce2315 + 0f400e0.

Checklist results

• [✅] /timecurve/abc12 captures to localStorage — referralPathCapture.test.ts 5/5 vitest passing; Playwright referral-path.spec.ts confirms localStorage key yieldomega.ref.v1 set with code: 'abc12' after navigation.
• [✅] ?ref=abc12 overrides path when both present — applyReferralUrlCapture in referralStorage.ts calls captureFromRefQueryString(search) FIRST; short-circuits if query valid. Docstring and code path consistent.
• [✅] /timecurve/arena and /timecurve/protocol still show Arena/Protocol — TimeCurveBranchPage.tsx dispatches arena → TimeCurvePage, protocol → TimeCurveProtocolPage, else → TimeCurveSimplePage. extractReferralCodeFromPathname test explicitly rejects both segments.
• [⚠️] /referrals UI — arcade shell + register panel — structural code review OK (ReferralRegisterSection resolves registry via VITE_REFERRAL_REGISTRY_ADDRESS env var else TimeCurve referralRegistry() fallback; reads live REFERRAL_EACH_BPS; approve + registerCode flow present; stores plaintext in localStorage on success). Visual render not tested in this session — stack state doesn't match both post-launch + configured-registry requirements in one go, deferring browser walkthrough.
• [✅] Post-launch /home preservation — LaunchGate.tsx L65-66: post-launch routes are / → TimeCurveSimplePage (index), /home → HomePage. No /:slug catch-all exists. Protected from shadowing.

Follow-up (5% consistency pass on 0f400e0)

REFERRAL_EACH_BPS = 500 verified consistent across:

• contracts/src/TimeCurve.sol:76 — constant definition
• contracts/src/TimeCurve.sol:305 — applied in buy(): (charmWad × 500) / 10_000 = 5%
• contracts/PARAMETERS.md:41 — '5% referrer + 5% referee'
• contracts/test/TimeCurveReferral.t.sol:93 — reads from tc.REFERRAL_EACH_BPS() (not hardcoded, auto-follows future governance changes)
• docs/product/referrals.md — consistent

Frontend TimeCurvePage uses formatBpsAsPercent with 5.00% fallback when live read unavailable.

What I did NOT verify

• Visual render of /referrals page (arcade shell, hero, sections)
• On-chain registerCode tx against a live stack (approve → register → localStorage write flow)
• Leaderboard UI (not yet scoped in this ship per your comment)
• Contract-level slug registry + restricted-word set (umbrella items, not in this slice)

The umbrella items remain open in the body — this note signs off only on what landed in 7ce2315 + 0f400e0. Leaving issue open as the umbrella tracker; individual future shipped slices can be signed off similarly.

@PlasticDigits #43 verification on `7ce2315` + `0f400e0`. ## Checklist results - **[✅] `/timecurve/abc12` captures to localStorage** — `referralPathCapture.test.ts` 5/5 vitest passing; Playwright `referral-path.spec.ts` confirms localStorage key `yieldomega.ref.v1` set with `code: 'abc12'` after navigation. - **[✅] `?ref=abc12` overrides path when both present** — `applyReferralUrlCapture` in `referralStorage.ts` calls `captureFromRefQueryString(search)` FIRST; short-circuits if query valid. Docstring and code path consistent. - **[✅] `/timecurve/arena` and `/timecurve/protocol` still show Arena/Protocol** — `TimeCurveBranchPage.tsx` dispatches `arena` → `TimeCurvePage`, `protocol` → `TimeCurveProtocolPage`, else → `TimeCurveSimplePage`. `extractReferralCodeFromPathname` test explicitly rejects both segments. - **[⚠️] `/referrals` UI — arcade shell + register panel** — structural code review OK (`ReferralRegisterSection` resolves registry via `VITE_REFERRAL_REGISTRY_ADDRESS` env var else TimeCurve `referralRegistry()` fallback; reads live `REFERRAL_EACH_BPS`; approve + `registerCode` flow present; stores plaintext in localStorage on success). **Visual render not tested in this session** — stack state doesn't match both post-launch + configured-registry requirements in one go, deferring browser walkthrough. - **[✅] Post-launch `/home` preservation** — `LaunchGate.tsx` L65-66: post-launch routes are `/` → `TimeCurveSimplePage` (index), `/home` → `HomePage`. No `/:slug` catch-all exists. Protected from shadowing. ## Follow-up (5% consistency pass on `0f400e0`) `REFERRAL_EACH_BPS = 500` verified consistent across: - `contracts/src/TimeCurve.sol:76` — constant definition - `contracts/src/TimeCurve.sol:305` — applied in `buy()`: `(charmWad × 500) / 10_000` = 5% - `contracts/PARAMETERS.md:41` — '5% referrer + 5% referee' - `contracts/test/TimeCurveReferral.t.sol:93` — reads from `tc.REFERRAL_EACH_BPS()` (not hardcoded, auto-follows future governance changes) - `docs/product/referrals.md` — consistent Frontend `TimeCurvePage` uses `formatBpsAsPercent` with 5.00% fallback when live read unavailable. ## What I did NOT verify - Visual render of `/referrals` page (arcade shell, hero, sections) - On-chain `registerCode` tx against a live stack (approve → register → localStorage write flow) - Leaderboard UI (not yet scoped in this ship per your comment) - Contract-level slug registry + restricted-word set (umbrella items, not in this slice) The umbrella items remain open in the body — this note signs off only on what landed in `7ce2315` + `0f400e0`. Leaving issue open as the umbrella tracker; individual future shipped slices can be signed off similarly.

Brouie commented 2026-04-23 06:24:52 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #42

mentioned in issue #42

PlasticDigits commented 2026-04-23 08:05:27 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

The visual render review is important - if it is challening enough to deserve its own issue, please open one. @Brouie

The visual render review is important - if it is challening enough to deserve its own issue, please open one. @Brouie

Brouie commented 2026-04-24 06:22:51 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #59

mentioned in issue #59

PlasticDigits (Migrated from gitlab.com) closed this issue 2026-04-24 12:25:27 +00:00

Brouie commented 2026-04-26 04:29:46 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #64

mentioned in issue #64

PlasticDigits commented 2026-05-20 04:19:09 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #223

mentioned in issue #223

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

cac-design-issue-544

renovate/configure

No results found.

Labels

Clear labels   

agent:fix_bugfix

  

agent:fix_conflicts

  

agent:fix_security

  

agent:gap_analysis

  

agent:implement

  

agent:open_issues

  

agents

  

agent:security_audit

  

agent:verify

  

area

timecurve

  

arena

  

arena-v2

  

audit

  

block:feature_review

  

block:security

  

bug

  

contracts

  

design

  

devops

  

docs

Documentation

  

documentation

  

enhancement

  

epic

Epic / umbrella issue

  

feature

  

frontend

  

indexer

  

low priority

Low priority, investigate other issues first

  

megaeth

  

operations

  

ops

Deploy and operations

  

performance

  

QA

  

qa checklist

  

referrals

  

removal

Legacy removal

  

security

  

smart-contracts

  

tech-debt

  

testing

  

time-arena

TimeArena v2 revamp

  

timecurve

  

visual-qa

No labels

agent:fix_bugfix

agent:fix_conflicts

agent:fix_security

agent:gap_analysis

agent:implement

agent:open_issues

agents

agent:security_audit

agent:verify

area

timecurve

arena

arena-v2

audit

block:feature_review

block:security

bug

contracts

design

devops

docs

documentation

enhancement

epic

feature

frontend

indexer

low priority

megaeth

operations

ops

performance

QA

qa checklist

referrals

removal

security

smart-contracts

tech-debt

testing

time-arena

timecurve

visual-qa

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

code/yieldomega#43

No description provided.