feat(creator): add TipLeaderboard component for creator profile page

.env.example

@@ -29,6 +29,20 @@ VITE_MAINNET_RPC_URL=
 # Stellar network for Stellar Expert explorer links.
 # Set to 'mainnet' for production, 'testnet' for development (default).
 VITE_STELLAR_NETWORK=testnet
+VITE_STELLAR_RPC_URL=
+# Horizon base URL used to poll transaction status after submission. Leave
+# unset to use the public Horizon endpoint for VITE_STELLAR_NETWORK.
+VITE_HORIZON_URL=
+VITE_CREATOR_KEYS_CONTRACT_ID=
+
+# WebSocket endpoint for the real-time key-price feed (optional). Leave unset to
+# disable the live feed — bonding-curve charts then rely on polled data only.
+# VITE_WEBSOCKET_URL=wss://stream.example.com/keys
+
+# Comma-separated wallet addresses allowed to deploy new creator keys through the
+# key factory wizard (optional). Leaving this unset fails closed and hides the wizard.
+# The factory contract still authorizes the deployment server-side.
+# VITE_KEY_FACTORY_WHITELIST=
 
 # UTM settings for shared profile links (optional)
 # Set any of these to enable UTM parameters on shared profile URLs.

.freebuff/project-id

@@ -0,0 +1 @@
+23786e79-6f9d-4ab3-90d8-f57510f217b4

.github/workflows/ci.yml

@@ -15,9 +15,9 @@ jobs:
            uses: actions/checkout@v4
 
          - name: Setup pnpm
-           uses: pnpm/action-setup@v4
-           with:
-              version: 10.6.5
+           run: |
+              corepack enable
+              corepack prepare pnpm@10.6.5 --activate
 
          - name: Setup Node.js
            uses: actions/setup-node@v4

.github/workflows/pr-target-check.yml

@@ -1,29 +1,29 @@
 name: Redirect PRs to dev
 
 on:
-  pull_request_target:
-    branches:
-      - main
+   pull_request_target:
+      branches:
+         - main
 
 jobs:
-  close-and-redirect:
-    runs-on: ubuntu-latest
-    permissions:
-      pull-requests: write
-    steps:
-      - name: Close PR and redirect to dev
-        uses: actions/github-script@v7
-        with:
-          script: |
-            await github.rest.issues.createComment({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              issue_number: context.payload.pull_request.number,
-              body: "👋 Thanks for your contribution! We don't accept pull requests directly to `main`. Please re-open your PR targeting the `dev` branch instead. See our contributing guide for details."
-            });
-            await github.rest.pulls.update({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              pull_number: context.payload.pull_request.number,
-              state: 'closed'
-            });
+   close-and-redirect:
+      runs-on: ubuntu-latest
+      permissions:
+         pull-requests: write
+      steps:
+         - name: Close PR and redirect to dev
+           uses: actions/github-script@v7
+           with:
+              script: |
+                 await github.rest.issues.createComment({
+                   owner: context.repo.owner,
+                   repo: context.repo.repo,
+                   issue_number: context.payload.pull_request.number,
+                   body: "👋 Thanks for your contribution! We don't accept pull requests directly to `main`. Please re-open your PR targeting the `dev` branch instead. See our contributing guide for details."
+                 });
+                 await github.rest.pulls.update({
+                   owner: context.repo.owner,
+                   repo: context.repo.repo,
+                   pull_number: context.payload.pull_request.number,
+                   state: 'closed'
+                 });

.gitignore

@@ -28,6 +28,8 @@ dist-ssr
 issue.md
 pr.md
 
+# MiMoCode
+.mimocode/
 # Test artifacts
 __snapshots__
 *.snap
@@ -39,4 +41,4 @@ Thumbs.db
 
 # Lock files from other package managers
 package-lock.json
-yarn.lock
+yarn.lock

.kiro/specs/holder-count-cache-invalidation-test/tasks.md

@@ -42,9 +42,9 @@ The production diff is intentionally small: one utility file, one hook, one comp
    - Verify `LandingPage.tsx` still compiles and the keyboard test (`LandingPage.keyboard.test.tsx`) still passes
    - _Requirements: 1.1, 3.4_
 
-- [ ] 5. Write the integration test
+- [x] 5. Write the integration test
    - Create `src/pages/__tests__/holderCountCacheInvalidation.test.tsx`
-   - [ ] 5.1 Set up test scaffolding
+   - [x] 5.1 Set up test scaffolding
       - Import `QueryClient`, `QueryClientProvider` from `@tanstack/react-query`; `MemoryRouter` from `react-router`; `render`, `screen`, `waitFor`, `act` from `@testing-library/react`; `fc` from `fast-check`; `beforeEach`, `afterEach`, `describe`, `expect`, `it`, `vi` from `vitest`
       - Import `FeaturedCreatorAudienceChip` from `@/components/common/FeaturedCreatorAudienceChip`
       - Import `getFeaturedCreatorKeyHolderCopy` from `@/utils/holderCount.utils`
@@ -56,42 +56,42 @@ The production diff is intentionally small: one utility file, one hook, one comp
       - Implement `createWrapper(queryClient)` returning a component that wraps children in `<QueryClientProvider>` + `<MemoryRouter>`
       - _Requirements: 4.1, 4.2, 4.3, 4.4_
 
-   - [ ] 5.2 Write property test for Property 1 — initial render round-trip
+   - [x] 5.2 Write property test for Property 1 — initial render round-trip
       - **Property 1: Initial render round-trip**
       - **Validates: Requirements 1.1, 5.4**
       - Use `fc.asyncProperty(fc.integer({ min: 1, max: 1_000_000 }), ...)` with `numRuns: 100`
       - For each `count`: create fresh `queryClient`, seed with `queryClient.setQueryData(['creator', CREATOR_ID, 'holderCount'], count)`, render `FeaturedCreatorAudienceChip` with wrapper, assert `screen.getByText(getFeaturedCreatorKeyHolderCopy(count).value)` is in the document, assert `mockFetchHolderCount` was NOT called, then `unmount()`
       - _Requirements: 1.1, 1.2, 5.4_
 
-   - [ ] 5.3 Write property test for Property 2 — stale-while-revalidate display stability
+   - [x] 5.3 Write property test for Property 2 — stale-while-revalidate display stability
       - **Property 2: Stale-while-revalidate display stability**
       - **Validates: Requirements 2.3**
       - Use `fc.asyncProperty(fc.integer({ min: 1, max: 1_000_000 }), ...)` with `numRuns: 100`
       - For each `initialCount`: seed cache, render component, call `queryClient.invalidateQueries` but do NOT resolve the pending `mockFetchHolderCount` (use a `Promise` that never resolves during the assertion window), assert old value is still visible and no blank/error state
       - _Requirements: 2.3_
 
-   - [ ] 5.4 Write property test for Property 3 — post-invalidation update round-trip
+   - [x] 5.4 Write property test for Property 3 — post-invalidation update round-trip
       - **Property 3: Post-invalidation update round-trip**
       - **Validates: Requirements 3.1, 3.2, 3.4**
       - Use `fc.asyncProperty(fc.integer({ min: 1, max: 999 }), fc.integer({ min: 1000, max: 1_000_000 }), ...)` with `numRuns: 100` (disjoint ranges guarantee `initialCount !== updatedCount`)
       - For each pair `(initialCount, updatedCount)`: seed cache with `initialCount`, render, spy on `window.location.reload`, invalidate query, await `waitFor` assertion that updated text is visible and old text is gone, assert `reloadSpy` was NOT called, `unmount()`
       - _Requirements: 3.1, 3.2, 3.3, 3.4_
 
-   - [ ] 5.5 Write property test for Property 4 — format function round-trip
+   - [x] 5.5 Write property test for Property 4 — format function round-trip
       - **Property 4: Format function round-trip**
       - **Validates: Requirements 5.1, 5.4**
       - Use synchronous `fc.property(fc.integer({ min: 1, max: 10_000_000 }), ...)` with `numRuns: 200`
       - For each `n > 0`: assert `getFeaturedCreatorKeyHolderCopy(n).value === formatCompactNumber(n) + ' key holders'`
       - _Requirements: 5.1, 5.4_
 
-   - [ ]\* 5.6 Write edge-case tests
+   - [x]\* 5.6 Write edge-case tests
       - `count = 0` renders `"No key holders yet"` — seed cache with `0`, render, assert text present
       - `count = null` renders `"Key holders unavailable"` — seed cache with `null`, render, assert text present
       - Non-matching query key: invalidate a different key, assert `mockFetchHolderCount` was NOT called and display is unchanged
       - After invalidation + resolved refetch: assert `mockFetchHolderCount` was called exactly once with `CREATOR_ID`
       - _Requirements: 1.3, 1.4, 2.2, 2.4_
 
-- [ ] 6. Checkpoint — run tests and confirm everything passes
+- [x] 6. Checkpoint — run tests and confirm everything passes
    - Run `pnpm test` (or `pnpm vitest run`) from `accesslayer-client--fork/`
    - Confirm `holderCountCacheInvalidation.test.tsx` passes all property and edge-case tests
    - Confirm `LandingPage.keyboard.test.tsx` still passes (no regression from Task 4 changes)

CONTRIBUTING.md

@@ -145,3 +145,4 @@ Issues labeled `good first issue` should:
 ## Questions
 
 If something is unclear, open a documentation issue or ask in the repo before starting implementation.
+..

docs/CurveMigrationPanel.md

@@ -0,0 +1,75 @@
+# Curve Migration Panel
+
+Creator-only management surface for the bonding-curve migrations queued against
+a creator key. It lives in the **Governance** tab of the creator dashboard
+(`src/pages/CreatorDashboardPage.tsx`).
+
+- Component: `CurveMigrationPanel`
+- File: `src/components/common/CurveMigrationPanel.tsx`
+- Hook: `useCurveMigrations` — `src/hooks/useCurveMigrations.ts`
+- Service: `curveMigrationService` — `src/services/curveMigration.service.ts`
+- Types: `src/types/curveMigration.ts`
+- Pure helpers: `src/utils/curveMigration.utils.ts`
+- Execute mutation: `useExecuteCurveMigrationMutation` —
+  `src/hooks/useCreatorContractActions.ts`
+
+## Why
+
+A curve migration changes the price every holder buys and sells at, so it is
+governed rather than applied directly. Two **independent** gates must both be
+satisfied before the creator can execute one:
+
+1. **Vote approval** — quorum reached _and_ more weight `for` than `against`.
+2. **Timelock elapsed** — the post-vote delay has passed, giving holders a
+   window to exit before the new pricing goes live.
+
+Either gate being unmet keeps Execute disabled, and the panel shows which one is
+still blocking.
+
+## What the panel renders
+
+| Region          | Test id                              | Contents                                                                                                                |
+| --------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| Pending list    | `curve-migration-pending-section`    | One card per `pending` migration, soonest timelock first                                                                |
+| Proposed params | `curve-migration-params-{id}`        | `from → to` diff of base price, growth factor, and graduated curve tiers; unchanged params carry `data-changed="false"` |
+| Timelock        | `curve-migration-timelock-{id}`      | Live `HH:MM:SS` countdown, or `Ready` once elapsed                                                                      |
+| Vote approval   | `curve-migration-vote-approval-{id}` | Share of cast weight that voted `for`                                                                                   |
+| Vote status     | `curve-migration-vote-status-{id}`   | `Approved` / `Not approved`, with quorum and participation below                                                        |
+| Execute         | `curve-migration-execute-{id}`       | Enabled only when both gates pass                                                                                       |
+| History         | `curve-migration-history-section`    | Executed migrations with applied params and execution date                                                              |
+
+The countdown only re-renders while a timelock is actually running.
+
+## Visibility
+
+`CreatorDashboardPage` gates the section on `isKeyCreator` — the connected
+wallet must match the key's `instructorId`. For non-creators the section is not
+rendered at all **and** the `useCurveMigrations` query stays disabled, so no
+migration data is fetched for wallets that cannot act on it.
+
+## Execute call
+
+Executing submits `execute_curve_migration`, built by the pure
+`buildCurveMigrationExecuteCall` helper so the exact call is assertable without
+signing anything:
+
+```ts
+buildCurveMigrationExecuteCall({ creatorId, migrationId });
+// { functionName: 'execute_curve_migration', args: { creatorId, migrationId } }
+```
+
+On success both cache layers are invalidated together — the 15s
+`curve_migrations_{keyId}` entry and the
+`queryKeys.creators.curveMigrations(creatorId)` query — so the migration moves
+from the pending list into the history with the params it actually applied.
+
+## Local validation
+
+```bash
+pnpm test src/utils/__tests__/curveMigration.utils.test.ts
+pnpm test src/services/__tests__/curveMigration.service.test.ts
+pnpm test src/hooks/__tests__/useCurveMigrations.test.tsx
+pnpm test src/hooks/__tests__/useCreatorContractActions.curveMigration.test.tsx
+pnpm test src/components/common/__tests__/CurveMigrationPanel.test.tsx
+pnpm test src/pages/__tests__/CreatorDashboardPage.curveMigration.integration.test.tsx
+```

docs/LpPositionManagement.md

@@ -0,0 +1,103 @@
+# LP Position Management (Portfolio → Liquidity)
+
+The **Liquidity** tab on `/profile` (and `/profile/:wallet`, read-only) lets a
+liquidity provider see their active LP positions and manage them (#1030).
+
+## What it shows
+
+- **Total LP earnings** card: unclaimed rewards + rewards already claimed from
+  the active positions, plus a position count.
+- One row per active position: pool / key name, contributed amount, pool
+  share %, accrued (unclaimed) rewards, and lock status.
+- Per-position actions, rendered only when the connected Stellar signer owns
+  the positions: **Add liquidity**, **Claim rewards**, **Remove liquidity**.
+
+## Where the data comes from
+
+| Concern                  | Source                                                                                                                  | Code                                 |
+| ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
+| Positions, rewards, lock | `GET /lp/positions?wallet=` (accesslayer-server #980)                                                                   | `services/lpPositions.service.ts`    |
+| Pool size, APR estimate  | `GET /lp/pool/:keyId` (accesslayer-server #980)                                                                         | `services/lpPositions.service.ts`    |
+| Spendable XLM            | Account ledger entry over Soroban RPC (`VITE_STELLAR_RPC_URL`)                                                          | `services/stellarAccount.service.ts` |
+| Add / claim / remove     | Creator Keys contract `add_liquidity` / `claim_lp_rewards` / `remove_liquidity` (accesslayer-contracts #1002, PR #1004) | `services/lpContract.service.ts`     |
+
+Hooks live in `hooks/useLpPositions.ts`; pure math lives in
+`utils/lpPositions.utils.ts`.
+
+### Expected API shapes
+
+The server endpoints are specified in accesslayer-server #980 but were not
+merged when this UI was built. The client expects the following shape and
+validates every field. Amounts are **stroops as integer strings** (i128 in
+the contract); numbers are accepted only when they are safe integers.
+
+```jsonc
+// GET /lp/positions?wallet=G...  →  APIResponse<{ positions: [...] }> (a bare array also works)
+{
+	"lpId": "7", // contract lp_id (u64)
+	"keyId": "C...", // contract key_id (Address)
+	"keyName": "Alpha Key", // optional, falls back to a shortened keyId
+	"creatorId": "alpha", // optional, enables the /creator/:id link
+	"contribution": "250000000",
+	"share": 2500, // optional, contract basis points
+	"poolTotalLiquidity": "1000000000", // optional, preferred for an exact share
+	"pendingRewards": "12345", // missing/invalid → shown as "Unavailable"
+	"claimedRewards": "100", // optional, lifetime claimed from this position
+	"unlocksAt": "2030-01-01T00:00:00Z", // optional; ISO, epoch s, or epoch ms
+}
+
+// GET /lp/pool/:keyId  →  APIResponse<{ keyId, totalLiquidity, aprBps }>
+```
+
+Records missing `lpId`, `keyId`, or a valid `contribution` are dropped, as are
+closed positions (`contribution = 0`, which is how the contract reports them).
+
+## Rules the UI follows
+
+- **Precision.** All amounts are `bigint` stroops end to end and are rendered
+  with 7 decimals via `formatXlm`, so tiny rewards never display as `0.00`.
+- **Pool share** is `contribution / poolTotalLiquidity` in integer math,
+  floored to 0.01%. A non-zero share under 0.01% reads `<0.01%`. If the pool
+  total is missing, the contract's basis-point `share` is used instead.
+- **Earnings total** de-duplicates by `lpId` and is withheld ("Unavailable")
+  when any position's rewards can't be read, rather than showing a partial sum.
+- **Add liquidity** validates format, > 0, ≤ 7 decimals, and ≤ spendable XLM
+  (balance minus account reserve and selling liabilities). The mutation reads
+  the balance again right before signing, so a balance that dropped after the
+  modal opened is caught.
+- **Reward rate preview** shows the API's APR estimate and the pool share the
+  deposit would receive using the contract formula
+  `amount / (total_liquidity + amount)`. No reward-rate formula is invented
+  client-side; if the API has no APR the preview says "Unavailable".
+- **Claim** simulates `claim_lp_rewards` first. If the contract would pay out
+  zero, the wallet is never prompted.
+- **Remove** is disabled while `unlocksAt` is in the future, with a live
+  countdown (`2d 14h 32m`). An unparseable `unlocksAt` blocks removal. Before
+  signing, the mutation refetches positions and re-checks the lock, and the
+  contract simulation has the final say.
+- **Confirmation.** Success toasts (with tx hash and Stellar Expert link)
+  appear only after `getTransaction` reports `SUCCESS`. A transaction that
+  lands but fails on-chain surfaces as an error.
+- **Refresh.** After a confirmed transaction the hooks invalidate
+  `queryKeys.lp.positions(wallet)`, `queryKeys.lp.pool(keyId)`, and
+  `queryKeys.wallet.xlmBalance(wallet)`. Positions also refetch every 30s and
+  when a lock countdown reaches zero.
+
+## Known limitations
+
+- **Lock period:** the LP reward contract in PR #1004 has no lock. `unlocksAt`
+  is honoured if the API provides it. Without it, removal is allowed and the
+  contract decides.
+- **Asset:** the contract does not name the deposited token. The UI assumes
+  XLM (stroops, 7 decimals) like every other amount in the app.
+- **Entry point:** "Add liquidity" is offered per existing pool. Opening a
+  first position in a new pool needs an entry point on the creator page,
+  which is outside this tab's scope.
+- **Base reserve** is fixed at 0.5 XLM (`BASE_RESERVE_STROOPS`), the current
+  value on mainnet and testnet.
+
+## Configuration
+
+Requires `VITE_STELLAR_RPC_URL` and `VITE_CREATOR_KEYS_CONTRACT_ID` (see
+`.env.example`). Without them, reads from the API still work but actions show
+a clear "not configured" error.

docs/adding-page-and-data-fetching.md

@@ -165,12 +165,8 @@ export const queryKeys = {
 import type { GetYourParams } from '@/services/your.service';
 
 export const queryKeys = {
-	creators: {
-		/* ... */
-	},
-	wallet: {
-		/* ... */
-	},
+	creators: {/* ... */},
+	wallet: {/* ... */},
 	yourEntity: {
 		all: ['yourEntity'] as const,
 		list: (params?: GetYourParams) =>