diff --git a/deploying.md b/deploying.md index 7a439eadd..255a05db9 100644 --- a/deploying.md +++ b/deploying.md @@ -5,6 +5,6 @@ Before starting the process ensure that you're a member of the reservoir0x organ ### Generating a Build 1. Switch to the main branch and pull to get the latest. -2. Go into each of the package folders being updated and run `yarn version:update X`, replace X with the correct release type (patch, minor or major). Patch is for small bugs that do not impact ux or have breaking changes. Minor is for breaking changes or new features. Major is for complete refactors of existing logic and funcionality. Running this command will update the version of the package json, commit the changes, tag the commit and push the code. +2. Go into each of the package folders being updated and run `yarn version:update X`, replace X with the correct release type (patch, minor or major). Patch is for small bugs that do not impact ux or have breaking changes. Minor is for breaking changes or new features. Major is for complete refactors of existing logic and functionality. Running this command will update the version of the package json, commit the changes, tag the commit and push the code. 3. All that's left to do is run `yarn publish:stable` at the root level, this will build all packages and deploy to npm only the ones marked with a new version. 4. Now run `yarn changelog` at the root level, this will generate the changelog and commit the changes. Review the generated changelog files before pushing the changes, make sure to clean up the title of each merge to make it more readable and add any additional information that may be useful. diff --git a/packages/sdk/src/types/api.ts b/packages/sdk/src/types/api.ts index 3c8540586..4c9c36654 100644 --- a/packages/sdk/src/types/api.ts +++ b/packages/sdk/src/types/api.ts @@ -297,7 +297,7 @@ export interface paths { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. */ get: operations["getEventsBidsV3"]; }; @@ -586,7 +586,7 @@ export interface paths { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -620,7 +620,7 @@ export interface paths { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -658,7 +658,7 @@ export interface paths { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the top bid changes. So if a new order or sale happens without changing the top bid, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -690,7 +690,7 @@ export interface paths { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -722,7 +722,7 @@ export interface paths { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -756,14 +756,14 @@ export interface paths { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ get: operations["getEventsTokensFlooraskV4"]; }; "/oracle/collections/bid-ask-midpoint/v1": { - /** Get a signed message of any collection's bid-ask midpoint (spot or twap). This is approximation of the colletion price. The oracle's address is 0xAeB1D03929bF87F69888f381e73FBf75753d75AF. The address is the same for all chains. */ + /** Get a signed message of any collection's bid-ask midpoint (spot or twap). This is approximation of the collection price. The oracle's address is 0xAeB1D03929bF87F69888f381e73FBf75753d75AF. The address is the same for all chains. */ get: operations["getOracleCollectionsBidaskmidpointV1"]; }; "/oracle/collections/floor-ask/v4": { @@ -6900,7 +6900,7 @@ export interface definitions { executionMethod?: "intent"; /** @description Referrer address (where supported) */ referrer?: string; - /** @description Mint comment (where suported) */ + /** @description Mint comment (where supported) */ comment?: string; /** @description Conduit key to use to fulfill the order */ conduitKey?: string; @@ -7366,7 +7366,7 @@ export interface definitions { skipBalanceCheck?: boolean; /** @description Referrer address (where supported). */ referrer?: string; - /** @description Mint comment (where suported). */ + /** @description Mint comment (where supported). */ comment?: string; }; Model603: { @@ -8106,7 +8106,7 @@ export interface operations { name?: string; /** Maximum floor price of the collection */ maxFloorAskPrice?: number; - /** Minumum floor price of the collection */ + /** Minimum floor price of the collection */ minFloorAskPrice?: number; /** If true, top bid will be returned in the response. */ includeTopBid?: boolean; @@ -8162,7 +8162,7 @@ export interface operations { name?: string; /** Maximum floor price of the collection */ maxFloorAskPrice?: number; - /** Minumum floor price of the collection */ + /** Minimum floor price of the collection */ minFloorAskPrice?: number; /** If true, attributes will be included in the response. Must filter by `id` or `slug` to a particular collection. */ includeAttributes?: boolean; @@ -8222,7 +8222,7 @@ export interface operations { name?: string; /** Maximum floor price of the collection */ maxFloorAskPrice?: number; - /** Minumum floor price of the collection */ + /** Minimum floor price of the collection */ minFloorAskPrice?: number; /** If true, attributes will be included in the response. Must filter by `id` or `slug` to a particular collection. */ includeAttributes?: boolean; @@ -9677,7 +9677,7 @@ export interface operations { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. */ getEventsBidsV3: { parameters: { @@ -11495,7 +11495,7 @@ export interface operations { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11554,7 +11554,7 @@ export interface operations { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11640,7 +11640,7 @@ export interface operations { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the top bid changes. So if a new order or sale happens without changing the top bid, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11695,7 +11695,7 @@ export interface operations { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11746,7 +11746,7 @@ export interface operations { * * Some considerations to keep in mind * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11803,7 +11803,7 @@ export interface operations { * * - Selling a partial quantity of available 1155 tokens in a listing will generate a `sale` and will have a new quantity. * - * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficent for keeping an external system in sync with the best available prices. + * - Due to the complex nature of monitoring off-chain liquidity across multiple marketplaces, including dealing with block re-orgs, events should be considered 'relative' to the perspective of the indexer, ie _when they were discovered_, rather than _when they happened_. A more deterministic historical record of price changes is in development, but in the meantime, this method is sufficient for keeping an external system in sync with the best available prices. * * - Events are only generated if the best price changes. So if a new order or sale happens without changing the best price, no event is generated. This is more common with 1155 tokens, which have multiple owners and more depth. For this reason, if you need sales data, use the Sales API. */ @@ -11834,7 +11834,7 @@ export interface operations { }; }; }; - /** Get a signed message of any collection's bid-ask midpoint (spot or twap). This is approximation of the colletion price. The oracle's address is 0xAeB1D03929bF87F69888f381e73FBf75753d75AF. The address is the same for all chains. */ + /** Get a signed message of any collection's bid-ask midpoint (spot or twap). This is approximation of the collection price. The oracle's address is 0xAeB1D03929bF87F69888f381e73FBf75753d75AF. The address is the same for all chains. */ getOracleCollectionsBidaskmidpointV1: { parameters: { query: { diff --git a/packages/ui/src/constants/wrappedContractNames.ts b/packages/ui/src/constants/wrappedContractNames.ts index 2f179b0e5..7a5e04ec6 100644 --- a/packages/ui/src/constants/wrappedContractNames.ts +++ b/packages/ui/src/constants/wrappedContractNames.ts @@ -8,7 +8,7 @@ const wrappedContractNames: Record = { 324: 'WETH', //weth 42161: 'WETH', //arbitrum 42170: 'WETH', //arbitrum nova - 43114: 'WAVAX', //avalance + 43114: 'WAVAX', //avalanche 59144: 'WETH', 999: 'WETH', //zoratestnet 80002: 'WMATIC', //amoy diff --git a/packages/ui/src/constants/wrappedContracts.ts b/packages/ui/src/constants/wrappedContracts.ts index e1341a843..764a9c0d6 100644 --- a/packages/ui/src/constants/wrappedContracts.ts +++ b/packages/ui/src/constants/wrappedContracts.ts @@ -8,7 +8,7 @@ const wrappedContracts: Record = { 1101: '0x4f9a0e7fd2bf6067db6994cf12e4495df938e6e9', // zkEVM 42161: '0x82af49447d8a07e3bd95bd0d56f35241523fbab1', //arbitrum 42170: '0x722e8bdd2ce80a4422e880164f2079488e115365', //arbitrum nova - 43114: '0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7', //avalance + 43114: '0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7', //avalanche 59144: '0xe5d7c2a44ffddf6b295a15c148167daaaf5cf34f', 999: '0x8a5027ea12f45a13deb6CB96A07913c6e192BE84', //zoratestnet 80002: '0x0ae690aad8663aab12a671a6a0d74242332de85f', //amoy diff --git a/packages/ui/src/modal/mint/MintModalRenderer.tsx b/packages/ui/src/modal/mint/MintModalRenderer.tsx index ae86ebb5c..1d320b106 100644 --- a/packages/ui/src/modal/mint/MintModalRenderer.tsx +++ b/packages/ui/src/modal/mint/MintModalRenderer.tsx @@ -334,7 +334,7 @@ export const MintModalRenderer: FC = ({ //Hardcoded to 30k items if unlimited maxQuantity = 30000 } else if (!currentQuantity.maxQuantity) { - // if value is undefined, we don't know max quantity, but simulation succeeed with quantity of 1 + // if value is undefined, we don't know max quantity, but simulation succeed with quantity of 1 maxQuantity = 1 } else { maxQuantity = Number(currentQuantity.maxQuantity ?? 0) @@ -345,7 +345,7 @@ export const MintModalRenderer: FC = ({ ) } else { let maxQuantity = data.maxQuantities?.[0].maxQuantity - // if value is null/undefined, we don't know max quantity, but simulation succeeed with quantity of 1 + // if value is null/undefined, we don't know max quantity, but simulation succeed with quantity of 1 totalMaxQuantity = maxQuantity ? Number(maxQuantity) : 1 } } diff --git a/packages/ui/src/modal/sweep/SweepModalRenderer.tsx b/packages/ui/src/modal/sweep/SweepModalRenderer.tsx index a58387314..d6f75951d 100644 --- a/packages/ui/src/modal/sweep/SweepModalRenderer.tsx +++ b/packages/ui/src/modal/sweep/SweepModalRenderer.tsx @@ -369,7 +369,7 @@ export const SweepModalRenderer: FC = ({ ) } else { let maxQuantity = data.maxQuantities?.[0].maxQuantity - // if value is null/undefined, we don't know max quantity, but simulation succeeed with quantity of 1 + // if value is null/undefined, we don't know max quantity, but simulation succeed with quantity of 1 totalMaxQuantity = maxQuantity ? Number(maxQuantity) : 1 } }