feat: add cryptoNetwork field to RealtimeFundingQuoteSource

[kphurley7]

Summary

Adds an optional cryptoNetwork field to RealtimeFundingQuoteSource.

Callers depositing stablecoins (USDC, USDT) via realtime funding need to specify which network they are depositing on so the server can generate a deposit address on the correct network. Without this field, the server has to hardcode the network (e.g. Solana devnet for sandbox), which won't work when production supports multiple networks.

The field is optional for backward compatibility — existing fiat realtime funding sources (USD, MXN, etc.) are unaffected.

Usage

{
  "source": {
    "sourceType": "REALTIME_FUNDING",
    "currency": "USDC",
    "cryptoNetwork": "SOLANA_MAINNET",
    "customerId": "Customer:..."
  }
}

Test plan

• Confirm existing fiat realtime funding quote tests still pass (no cryptoNetwork required)
• Confirm USDC realtime funding quote with cryptoNetwork: "SOLANA_MAINNET" returns a Solana deposit address
• OpenAPI lint passes (make lint)

🤖 Generated with Claude Code

[github-actions]

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

openapi

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

python

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

typescript

feat: add cryptoNetwork field to RealtimeFundingQuoteSource

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅

✅ grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

pip install https://pkg.stainless.com/s/grid-python/e556863727aafbd29505af5006325d94de85647a/grid-0.0.1-py3-none-any.whl

✅ grid-kotlin studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

✅ grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/09b91d5511100be716a7d2472558ece95178793b/dist.tar.gz

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-02-27 20:17:04 UTC

[greptile-apps]

Greptile Summary

Added optional cryptoNetwork field to RealtimeFundingQuoteSource schema to enable multi-network stablecoin deposits. This allows callers to specify which network (e.g., SOLANA_MAINNET, ETHEREUM_MAINNET) they'll deposit USDC/USDT on, enabling the server to generate deposit addresses on the correct network.

• Backward compatible: Field is optional and only required for stablecoin currencies
• Well documented: Clear description with example values in the schema
• Correct workflow: Source schema edited in openapi/ directory, then make build run to update generated bundles
• No issues found: Clean implementation following OpenAPI best practices

Confidence Score: 5/5

• This PR is safe to merge with no issues identified
• The change is a straightforward schema addition that maintains backward compatibility. The optional field is well-documented with clear examples, follows proper OpenAPI conventions, and solves a real need for multi-network stablecoin support. All three files were correctly updated following the project's workflow (source edit + make build).
• No files require special attention

Important Files Changed

Filename	Overview
openapi/components/schemas/quotes/RealtimeFundingQuoteSource.yaml	Added optional cryptoNetwork field with clear documentation and examples for stablecoin network selection
openapi.yaml	Generated bundle correctly updated with new cryptoNetwork field from source schema
mintlify/openapi.yaml	Generated bundle correctly updated with new cryptoNetwork field for documentation

_{Last reviewed commit: a14bb9d}

[pengying]

@wuvictor-95 I thought we were going to return an array of all supported networks in the quote response payment instructions?

[wuvictor-95]

It's what we are doing currently since we only have one network. In the future though, as we expand our capabilities to many networks, it makes less sense to do. We wouldn't want to create 3+ garbage deposit addresses for different networks everytime we create a quote

[pengying]

Oh man. This is another breaking change. And I thought address generation was cheap and we were going to use that pattern for other payment instructions.

[wuvictor-95]

This could be handled via config e.g. platform specifies which networks they care about when funding payments. Default is solana.

Yea, it's cheap but not 0. We have to check in each address to be watched on Alchemy, and alchemy has limits. It's definitely not scalable to, say, spin up 5 addresses for every payment. But perhaps we can manage that complexity and clean up all the addresses after 24 hours.

[pengying]

It's better to get breaking changes in now. I do think it's a better experience to be able to accept across multiple chains. As an example if I'm depositing to Uniswap, I generate the address once and can send to it from any network. Vs needing to specify the network prior to address generation.

[wuvictor-95]

Yea, I think it really depends on the use case. I can totally see a platform who can fulfill payments on behalf of users, and gives the user multiple options on how to fund the payment.

It's possible to manage the complexity on our side and always present multiple deposit addresses. I'm ok with leaving as is if you see viable use cases.

[jklein24]

This isn't actually technically a breaking change though from an API standpoint since we're adding a new optional field. We could just return all available networks if no network is specified, right? Or we could just error out and then the like 3 people testing sandbox will see it and we can flag that we're adding this in sandbox. Not a huge deal imo.