@circle-fin/provider-cctp-v2 1.0.4 → 1.1.0

package/CHANGELOG.md

@@ -1,5 +1,45 @@
 # @circle-fin/provider-cctp-v2
 
+## 1.1.0
+
+### Minor Changes
+
+- Add `reAttest` method to `CCTPV2BridgingProvider` for handling expired attestations.
+
+  When a CCTP v2 attestation expires before the mint transaction can be completed, users can now call `reAttest()` to request a fresh attestation using the original burn transaction hash.
+
+- **Enhanced bridge estimate response**: `EstimateResult` now includes `token`, `amount`, `source`, `destination` fields to provide complete transfer information alongside cost estimates.
+
+### Patch Changes
+
+- Fix fast burn fee calculation to handle decimal basis points from IRIS API
+
+  The IRIS API returns `minimumFee` as decimal basis points (e.g., `"1.3"` for 1.3 bps), but the code was attempting to convert this directly to `BigInt`, which fails for non-integer values. This caused `"Max fee must be less than amount"` errors during FAST transfers.
+
+## 1.0.5
+
+### Patch Changes
+
+- Improved how the retry function handles bridge transfers stuck in a pending state:
+  - The retry function now properly waits for pending transactions to complete before continuing with the next steps, instead of failing or skipping them
+  - Validates that required data (like transaction hashes) is present before attempting to continue, throwing clear errors immediately instead of failing silently
+  - Error messages now clearly indicate when "user action is required" for non-actionable states
+  - Validation errors during pending state resolution are no longer silently caught and now surface properly
+
+- Fix retry functionality when a custom `recipientAddress` is specified in bridge parameters. Previously, retry operations would fail attestation validation because the `recipientAddress` was not preserved in the bridge result, causing the system to use the adapter address instead of the originally specified recipient.
+- Validation errors now use standardized error codes for consistent error handling. All validation failures return the same `KitError` structure as other SDK errors.
+
+  **Migration:** If you're catching validation errors, update your error handling:
+  - Check `error.code === 1098` instead of `instanceof ValidationError`
+  - Access details via `error.cause?.trace?.validationErrors` instead of `error.errors`
+
+  The legacy `ValidationError` class remains available for backward compatibility.
+
+- **Improved retry() behavior for completed bridges**
+
+  -The `retry()` method now handles completed bridge operations gracefully:
+  Calling `retry()` on an already-completed bridge now returns successfully instead of throwing an error
+
 ## 1.0.4
 
 ### Patch Changes