Difficulty: Intermediate
Type: Performance
Recommended labels (if available in this repo): enhancement, performance, sdk
Background
src/contracts/providers/multicall3Provider.ts already exists, providing Multicall3 batching at the provider level. However, src/access/accessHelpers.ts does not yet use it — access checks that require multiple on-chain reads appear to issue them individually.
Problem
Multi-condition access checks (e.g. checking multiple role/token requirements for one resource) currently make N separate RPC calls instead of one batched Multicall3 call, increasing latency and RPC provider load.
Expected Outcome
accessHelpers.ts batches eligible on-chain read calls through the existing multicall3Provider.ts when checking multiple requirements for a single access decision.
Suggested Implementation
Identify the call sites in accessHelpers.ts that issue multiple independent contract reads for one access decision. Route them through multicall3Provider.ts instead of individual calls, preserving per-call error isolation (one failed sub-call shouldn't fail the whole batch if partial results are usable).
Acceptance Criteria
- Access checks with 2+ on-chain read requirements issue a single batched multicall instead of N separate calls
- Partial failure of one sub-call in the batch does not silently corrupt other results
- Unit tests verify batching behavior and partial-failure handling
- No change to the public
checkAccess() return type or behavior from the caller's perspective
pnpm test:run passes
Likely Affected Files/Directories
src/access/accessHelpers.ts
src/access/access.service.ts
src/contracts/providers/multicall3Provider.ts
Difficulty: Intermediate
Type: Performance
Recommended labels (if available in this repo):
enhancement,performance,sdkBackground
src/contracts/providers/multicall3Provider.tsalready exists, providing Multicall3 batching at the provider level. However,src/access/accessHelpers.tsdoes not yet use it — access checks that require multiple on-chain reads appear to issue them individually.Problem
Multi-condition access checks (e.g. checking multiple role/token requirements for one resource) currently make N separate RPC calls instead of one batched Multicall3 call, increasing latency and RPC provider load.
Expected Outcome
accessHelpers.tsbatches eligible on-chain read calls through the existingmulticall3Provider.tswhen checking multiple requirements for a single access decision.Suggested Implementation
Identify the call sites in
accessHelpers.tsthat issue multiple independent contract reads for one access decision. Route them throughmulticall3Provider.tsinstead of individual calls, preserving per-call error isolation (one failed sub-call shouldn't fail the whole batch if partial results are usable).Acceptance Criteria
checkAccess()return type or behavior from the caller's perspectivepnpm test:runpassesLikely Affected Files/Directories
src/access/accessHelpers.tssrc/access/access.service.tssrc/contracts/providers/multicall3Provider.ts