refactor: strategies

[gregdhill]

• Restrict GatewayQuoteParams to be more like TransferParams
• Adopt Token type from superchain repo
• Add getStrategies with Swing types

Process to integrate e.g. Pell Network without an output token:

const strategies = await gatewaySDK.getStrategies();
const contract = strategies.filter(strategy => strategy.integration.type === "staking")[0];

const params: GatewayQuoteParams = {
  toToken: contract.address, // NOTE: this is actually the strategy contract not the output token
  ...
};

const quote = await gatewaySDK.getQuote(params);

[changeset-bot]

⚠️ No Changeset found

Latest commit: 749b34d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
bob	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 30, 2024 5:19pm

[derrekcoleman]

My comments are mostly about the DX and UX for Bitcoin address validation.

If we don't have any opinions about what Bitcoin addresses are valid (e.g. p2tr), then I suppose we can ignore most of what I said and leave it up to the UI's implementation. For example, here's where our UI uses sats-wagmi to give the user a descriptive error for a taproot address.

Here's another example of stakingrewards.com just throwing up a box to make the user verify they don't hold ordinals in the address they use.

[derrekcoleman]

If a dev is going through the testnet workflow, they're meant to put fromChain: "Bitcoin", in their quoteParams? I found it clunky not to differentiate between Bitcoin mainnet and testnet, even though it seems like we're halfway to cleverly abstracting the need to be explicit about that away from the dev

[gregdhill]

Do you have a suggestion for a well-known chain slug? Happy to change it but couldn't think of anything

[derrekcoleman]

Under what conditions would the caller need to supply fromUserPublicKey? Are there already descriptive error messages for these edge cases?

Does it have to do with different Bitcoin address types? e.g. is fromUserAddress: "bc1qafk4yhqvj4wep57m62dgrmutldusqde8adh20d", in quoteParams sufficient?

TIA for the response; I suspect it would be useful in the docs.

[gregdhill]

Only required if the user is using P2SH-P2WPKH, we have some descriptive errors but agree we should note in the docs

[derrekcoleman]

Nice. I like introducing the monetization key now to align with Swing and set ourselves up for turning this on later.

[derrekcoleman]

Related to my Bitcoin address question above, I wonder if the DX (i.e. descriptive errors) around multiple Bitcoin address types could be useful here.

Most (all?) of the server-side testing uses the same mock Bitcoin address.

   fn mock_bitcoin_address() -> bitcoin::Address {
        bitcoin::Address::from_str("bcrt1qj4ymqevserwz045556l6qjycxnumcwwk09t3af")
            .unwrap()
            .assume_checked()
    }

I'm happy to help with test coverage (and perhaps the errors, if needed) if you can help me catch up to how we currently handle Bitcoin address validation.

[derrekcoleman]

Also approving so you can merge