[#539] Update StoryFactory to new v4 contract

[realproject7]

Summary

• Updated STORY_FACTORY mainnet address: 0x337c5b96... → 0x92c3bd44fda84e632c3c3cb31387d0c0c1de618d
• Updated DEPLOYMENT_BLOCK: 43609150 → 43824790 (v4 deploy block)
• Updated in both lib/contracts/constants.ts and packages/sdk/src/constants.ts
• .env.local updated locally (gitignored, needs Vercel env var update too)
• Bumped version to 0.1.11

Test plan

• App loads storylines from new contract
• Backfill cron scans from new deployment block
• Footer shows new contract address link
• Vercel env NEXT_PUBLIC_CONTRACT_ADDRESS needs updating (operator action)

Fixes #539

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Mar 25, 2026 0:05am

[project7-interns]

APPROVE — StoryFactory v4 address (0x92c3bd44...) and deployment block (43824790) updated in both lib/contracts/constants.ts and packages/sdk/src/constants.ts. Matches PR #66 deployment. No issues.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

Updating the StoryFactory constants is necessary, but issue #539 also requires reinitializing the backfill cursor for the new deployment. This PR does not do that, so existing deployments can keep scanning from the old persisted cursor state instead of from the new factory's start block.

Findings

• [high] The persisted backfill_cursor is not reset or reinitialized for the new StoryFactory deployment.
  • File: src/app/api/cron/backfill/route.ts:101
  • Suggestion: Add the missing DB/migration/reset step for backfill_cursor (id 1) so the app starts scanning the new factory from the new deployment block rather than trusting the old persisted cursor. The current route reads last_block from Supabase and derives fromBlock from that existing value; it does not fall back to the updated DEPLOYMENT_BLOCK, so changing the constants alone does not satisfy issue #539's backfill_cursor initialized acceptance criterion.

Decision

Requesting changes because the PR updates the addresses but not the persisted backfill state required to actually index the new StoryFactory deployment.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The new fallback to DEPLOYMENT_BLOCK is a partial improvement, but it still does not satisfy issue #539 for an existing deployment because it only applies when the cursor is missing or zero.

Findings

• [high] Existing backfill_cursor state is still not reinitialized for the new StoryFactory deployment.
  • File: src/app/api/cron/backfill/route.ts:109
  • Suggestion: Add the missing DB/migration/reset step for backfill_cursor id 1, or add explicit logic to detect the contract switch and reset the stored cursor to the new deployment block. The current code uses DEPLOYMENT_BLOCK only when last_block is falsy; any already-populated cursor will continue from the old persisted block and can skip the new factory's early events.

Decision

Requesting changes because the current head still does not initialize or reset the persisted cursor for the redeployed StoryFactory, which remains an explicit issue #539 requirement.

[project7-interns]

Re-reviewed — all three pieces in place: constants updated, backfill cron DEPLOYMENT_BLOCK fallback for fresh installs, and migration 00023 resets existing cursor to block 43824789 (one before v4 deploy). APPROVE.

[project7-interns]

Verdict: APPROVE

Summary

The updated head now includes the missing persisted-cursor reset for the new StoryFactory deployment. That closes the gap between the constant change and the actual indexing state transition required by issue #539.

Findings

• No blocking findings.

Decision

Approve. supabase/migrations/00023_reset_backfill_cursor_v4.sql now resets backfill_cursor id 1 to 43824789, so the backfill cron will pick up the v4 StoryFactory from the correct starting point even if the old cursor had already advanced past the new deployment block.