feat: add activity service

[Seranged]

Summary

• Add a V3-backed activityService to the Euler SDK for account and vault event timelines.
• Normalize activity rows with labels, categories, tx metadata, and common address helpers.
• Wire activity service config, env overrides, SDK exposure, query names, and public exports.

Tests

• pnpm --filter @eulerxyz/euler-v2-sdk test -- activityService.test.ts
• pnpm --filter @eulerxyz/euler-v2-sdk typecheck
• pnpm --filter @eulerxyz/euler-v2-sdk build
• Full SDK test suite also ran from the commit hook and passed.

[LeonardEulerXYZ]

Leonard review: Changes requested

Reviewed PR #66 at head 8bf86aa473cdd39ba131313f87449d9501b651a5.

The new V3-backed activity service is generally clean: endpoint wiring, API-key propagation, public root exports, query decoration, and event normalization all line up with the existing SDK service patterns. I found one SDK API-compatibility blocker before this should merge.

Blocking finding

• EulerSDKOptions now requires activityService. That makes the exported new EulerSDK({...}) constructor/options shape source-breaking for any integrator or test harness that constructs the exported class directly instead of going through buildEulerSDK().

Validation performed

• Diff/context review across all 10 changed files.
• V3 OpenAPI contract check for /v3/evc/accounts/{address}/events and /v3/evk/vaults/{chainId}/{address}/events.
• Live API smoke with ActivityService against mainnet USDC vault 0xD8b27CF359b7D15710a5BE299AF6e7Bf904984C2; response normalized and target contract helper returned the checksummed vault.
• pnpm install --frozen-lockfile
• pnpm --filter @eulerxyz/euler-v2-sdk test -- activityService.test.ts — passed; Vitest ran the full SDK suite, 27 files / 350 tests.
• pnpm --filter @eulerxyz/euler-v2-sdk typecheck — passed.
• pnpm --filter @eulerxyz/euler-v2-sdk build — passed; generated declarations include the new service exports.
• pnpm --filter @eulerxyz/euler-v2-sdk lint — exit 0 with existing unrelated Biome warnings in src/utils/*.
• git diff --check origin/main...HEAD — passed.
• Security/supply-chain sweep over the diff — no dependency, workflow, script, secret, or suspicious execution changes found.

Scalability / maintainability hygiene pass

Checked sibling V3-backed services, config/env precedence, buildQuery decoration, root/package exports, generated declarations, and service override wiring. The activity service follows the existing V3 service abstraction; no missed sibling flow or duplicated old behavior found beyond the constructor API break noted inline.

Bot/reviewer feedback

No active CodeRabbit/other bot comments or prior Leonard comments were present when reviewed.

Screenshots: not applicable; SDK-only change with no user-visible UI surface.

comment lifecycle: none found

[LeonardEulerXYZ]

Leonard re-review: Changes requested

Reviewed PR #66 at head b2380af2d1624709ccc60325554fbca8b8078d54.

The latest push adds useful coverage for activity-specific V3 config precedence, and the activity service itself continues to look coherent: default/export wiring, buildEulerSDK() integration, API-key propagation, query decoration, response normalization, and the live V3 account/vault event shape all line up.

The existing SDK API-compatibility blocker is still present, so I am keeping this as Changes requested.

Blocking finding

• EulerSDKOptions still requires activityService (packages/euler-v2-sdk/src/sdk/sdk.ts). Because EulerSDKOptions and EulerSDK are exported public API, this is source-breaking for direct new EulerSDK({...}) users who were previously passing the complete valid service set. The generated declaration also exposes activityService: IActivityService as required. The existing Leonard inline comment on the current head remains relevant.

A low-noise fix would be to keep buildEulerSDK() constructing the new service, but avoid making existing direct-constructor callers immediately fail TypeScript: for example, make the constructor option optional with a safe default/lazy fallback, or otherwise introduce the new member in a backwards-compatible way consistent with the package's semver expectations.

Validation performed

• Re-reviewed all 10 changed files and the delta from prior reviewed head 8bf86aa473cdd39ba131313f87449d9501b651a5 to current head b2380af2d1624709ccc60325554fbca8b8078d54 (test/activityService.test.ts only).
• pnpm install --frozen-lockfile — passed.
• pnpm --filter @eulerxyz/euler-v2-sdk test -- activityService.test.ts — passed; Vitest ran 27 files / 351 tests.
• pnpm --filter @eulerxyz/euler-v2-sdk typecheck — passed.
• pnpm --filter @eulerxyz/euler-v2-sdk build — passed; generated declarations include the new activity exports, and also confirm EulerSDKOptions.activityService is required.
• pnpm --filter @eulerxyz/euler-v2-sdk lint — exit 0, with pre-existing unrelated Biome warnings in src/utils/*.
• git diff --check origin/main...HEAD — passed.
• Live V3 smoke via built ActivityService against:
  • account 0xee5b5c82a365d75e9f8a1e982687fb5b6ceb606c
  • mainnet USDC vault 0xD8b27CF359b7D15710a5BE299AF6e7Bf904984C2
    Both endpoints returned 200 application/json; normalized categories/labels and target-contract extraction matched the fixture.
• Security/supply-chain sweep over the diff — no dependency, workflow, script, secret, package-export, transaction-construction, BigNumber/decimal, or suspicious execution changes found.

Scalability / maintainability hygiene pass

Started from the PR intent — a reusable activity timeline service — and checked sibling V3-backed service patterns, config/env precedence, buildQuery decoration, service override wiring, root/package exports, generated declarations, and tests. The activity service is the right reusable abstraction for account/vault timeline reads, and the new config precedence test covers the latest push. I did not find missed sibling flows or duplicated old behavior beyond the public constructor compatibility issue above.

Bot/reviewer feedback

No active CodeRabbit/other bot comments were present. The prior Leonard inline comment is still relevant on the current head.

Screenshots: not applicable; SDK-only change with no user-visible UI surface.

comment lifecycle: no Leonard top-level issue comment found to edit; kept the still-relevant Leonard inline comment on sdk.ts; no stale Leonard comments deleted.

[LeonardEulerXYZ]

Leonard re-review: Approved

Reviewed PR #66 at head 2f51bba94e726bce999630c35657a27ce826c638.

The latest push fixes the prior SDK API-compatibility blocker by keeping EulerSDKOptions.activityService optional and defaulting the constructor to a built-in ActivityService. That preserves direct new EulerSDK({...}) callers while still exposing sdk.activityService for normal buildEulerSDK() users. The activity service wiring, exports, env/config precedence, query decoration, API-key propagation, and event normalization all look coherent.

Validation performed

• Full diff/context review across all 10 changed files.
• Rechecked current GitHub PR metadata, prior Leonard reviews, prior Leonard inline comments, and active reviewer/bot feedback. No active CodeRabbit/other-bot findings were present; the stale Leonard inline blocker was deleted after verifying the fix.
• pnpm install --frozen-lockfile — passed.
• pnpm --filter @eulerxyz/euler-v2-sdk test -- activityService.test.ts — passed; Vitest ran 27 files / 352 tests.
• pnpm --filter @eulerxyz/euler-v2-sdk typecheck — passed.
• pnpm --filter @eulerxyz/euler-v2-sdk build — passed; generated declarations expose EulerSDKOptions.activityService?: IActivityService and sdk.activityService: IActivityService.
• pnpm --filter @eulerxyz/euler-v2-sdk lint — exit 0, with existing unrelated Biome warnings in src/utils/*.
• git diff --check origin/main...HEAD — passed.
• Live V3 API fixture checks against:
  • account events: /v3/evc/accounts/0xee5b5c82a365d75e9f8a1e982687fb5b6ceb606c/events?chainId=1&from=1725148800&to=1726358400&limit=2
  • vault events: /v3/evk/vaults/1/0xD8b27CF359b7D15710a5BE299AF6e7Bf904984C2/events?chainId=1&from=1725148800&to=1726358400&limit=2
    Both returned the expected { data, meta } shape with event fields consumed by the service.
• Security/supply-chain sweep over the diff: no dependency, workflow, script, secret, transaction-construction, shell-execution, or suspicious network-surface changes beyond the intended V3 activity fetches.

Scalability / maintainability hygiene pass

Started from the PR intent: add a reusable V3 activity read service to the SDK. I searched sibling services, config/env patterns, buildQuery decoration, root/package exports, generated declaration output, and similar V3-backed service wiring. The implementation follows the existing service abstraction rather than duplicating a one-off consumer path, adds focused tests for URL construction/normalization/config precedence/backwards-compatible constructor wiring, and does not leave a comparable sibling flow using an old behavior.

Screenshot evidence

Not applicable: this SDK PR has no user-visible UI surface to capture.

Verdict: approve.