Skip to content

feat: add cryptoNetwork field to RealtimeFundingQuoteSource #236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kphurley7 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat: add cryptoNetwork field to RealtimeFundingQuoteSource #236

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions mintlify/openapi.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 4 additions & 0 deletions openapi.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 8 additions & 0 deletions openapi/components/schemas/quotes/RealtimeFundingQuoteSource.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,14 @@ allOf:
[Supported Currencies](https://grid.lightspark.com/platform-overview/core-concepts/currencies-and-rails)
for the full list of supported fiat and crypto currencies.
example: USD
cryptoNetwork:
type: string
Copy link
Contributor

@pengying pengying Feb 27, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@wuvictor-95 wuvictor-95 Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@pengying pengying Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@wuvictor-95 wuvictor-95 Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@pengying pengying Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@wuvictor-95 wuvictor-95 Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@jklein24 jklein24 Feb 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

description: >-
The crypto network to use for the funding source. Required when `currency` is a
stablecoin (e.g. USDC, USDT). Specifies which network the customer will deposit
on, so the correct deposit address can be generated. Example values:
`SOLANA_MAINNET`, `SOLANA_DEVNET`, `ETHEREUM_MAINNET`.
example: SOLANA_MAINNET
description: >-
Fund the quote using a real-time funding source (RTP, SEPA Instant, Spark, Stables, etc.).
This will require manual just-in-time funding using `paymentInstructions` in the response.
Expand Down
Loading