Feat/gas and subgraph

[sirpy]

1. removed forcing of gasPrice and gasLimit
2. added subgraph data

TODO:

• verify that superfluid actions work without the chain overrides. does it use maxFeePerGas? does it estimate gas correctly?
• release the subgraph

Summary by Sourcery

Remove hardcoded gas overrides from GoodCollective SDK transactions and extend subgraph tracking for UBI claims and donor streaming contributions.

Enhancements:

• Let ethers and Superfluid estimate gas and pricing by removing chain-specific overrides from GoodCollective SDK contract interactions.
• Track UBI claim counts per steward and add streamed contribution totals for donors in the subgraph schema and mappings.

Build:

• Relax @uniswap/smart-order-router dependency to any 3.x version in the app package.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Removing CHAIN_OVERRIDES entirely may regress behavior on Celo-like networks that relied on explicit gasPrice/gasLimit (e.g., the previous 1,200,000 gas on approve); consider exposing optional overrides in the SDK methods so callers can still tune gas where needed instead of hardcoding or fully removing this capability.
• The new streamedContribution field on DonorCollective is not yet populated anywhere in the mappings; either wire it up in the relevant handlers or drop it until you are ready to support it to avoid confusion and unused schema surface.
• Relaxing @uniswap/smart-order-router to "3.*" could silently pull in future breaking changes within major 3; consider pinning to a specific minor/patch or using a caret range you are comfortable with to keep dependency behavior predictable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Removing `CHAIN_OVERRIDES` entirely may regress behavior on Celo-like networks that relied on explicit gasPrice/gasLimit (e.g., the previous 1,200,000 gas on approve); consider exposing optional overrides in the SDK methods so callers can still tune gas where needed instead of hardcoding or fully removing this capability.
- The new `streamedContribution` field on `DonorCollective` is not yet populated anywhere in the mappings; either wire it up in the relevant handlers or drop it until you are ready to support it to avoid confusion and unused schema surface.
- Relaxing `@uniswap/smart-order-router` to `"3.*"` could silently pull in future breaking changes within major 3; consider pinning to a specific minor/patch or using a caret range you are comfortable with to keep dependency behavior predictable.

## Individual Comments

### Comment 1
<location path="packages/subgraph/schema.graphql" line_range="48" />
<code_context>
+  """
+  Number of claims from ubi pools performed
+  """
+  claims: Int!
   totalEarned: BigInt!

</code_context>
<issue_to_address>
**suggestion (bug_risk):** New non-null `claims` field on `Steward` requires all mapping code to initialize it for existing and new entities.

Because `claims` is `Int!`, every existing and new `Steward` in the subgraph must have this field set. Any handler that creates or loads a `Steward` needs to initialize `claims` (e.g., default 0) or queries/mappings may fail. Also plan a migration/backfill for already-stored entities before deploying this change to an existing subgraph.

Suggested implementation:

```
  events: [SupportEvent!]! @derivedFrom(field: "donorCollective")
  """
  Number of actions performed
  """
  actions: Int!
  """
  Number of claims from ubi pools performed
  """
  claims: Int!
  totalEarned: BigInt!

```

To fully implement your suggestion about the non-null `claims: Int!` field on `Steward`, the following changes are also required in the mappings (not shown in the snippet):

1. In every handler/factory where a `Steward` is created (e.g., `new Steward(id)`), explicitly initialize `steward.claims = 0` before `steward.save()`.
2. In every handler where a `Steward` might be first loaded and then created if missing (`let steward = Steward.load(id)` pattern), ensure the new entity path also sets `claims = 0`.
3. For existing data in already-deployed subgraphs, implement a backfill/migration strategy:
   - Either deploy a temporary version that treats `claims` as nullable, initialize it via handlers (e.g. on next event per Steward) and then migrate to `Int!`, or
   - Redeploy from genesis (if feasible) with mappings that initialize `claims = 0` from the start.
4. Update any tests or data fixtures that construct `Steward` entities to include `claims` with a default value of `0`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[L03TJ3]

• By default it now only supplies gasLimit and leaves the rest up to connected wallet to fill in the blanks. Thats as was intended?