fix: Encrypt google kms key #603
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughMultiple string fields in Google Cloud KMS signer configurations are converted to Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. @@ Coverage Diff @@
## main #603 +/- ##
==========================================
+ Coverage 92.32% 92.34% +0.01%
==========================================
Files 258 259 +1
Lines 94352 95013 +661
==========================================
+ Hits 87112 87740 +628
- Misses 7240 7273 +33
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/models/signer/response.rs (1)
122-138: Consider simplifying theto_str().clone()pattern.The pattern
(*field.to_str()).clone()is verbose. Ifto_str()returns&str(which it typically does forSecretString), you can simplify tofield.to_str().to_string()orfield.to_str().to_owned().🔎 Suggested simplification
service_account: GoogleCloudKmsSignerServiceAccountResponseConfig { - project_id: (*c.service_account.project_id.to_str()).clone(), - client_id: (*c.service_account.client_id.to_str()).clone(), - auth_uri: (*c.service_account.auth_uri.to_str()).clone(), - token_uri: (*c.service_account.token_uri.to_str()).clone(), - auth_provider_x509_cert_url: (*c - .service_account - .auth_provider_x509_cert_url - .to_str()) - .clone(), - client_x509_cert_url: (*c.service_account.client_x509_cert_url.to_str()) - .clone(), - universe_domain: (*c.service_account.universe_domain.to_str()).clone(), + project_id: c.service_account.project_id.to_str().to_string(), + client_id: c.service_account.client_id.to_str().to_string(), + auth_uri: c.service_account.auth_uri.to_str().to_string(), + token_uri: c.service_account.token_uri.to_str().to_string(), + auth_provider_x509_cert_url: c.service_account.auth_provider_x509_cert_url.to_str().to_string(), + client_x509_cert_url: c.service_account.client_x509_cert_url.to_str().to_string(), + universe_domain: c.service_account.universe_domain.to_str().to_string(), }, key: GoogleCloudKmsSignerKeyResponseConfig { - location: (*c.key.location.to_str()).clone(), - key_ring_id: (*c.key.key_ring_id.to_str()).clone(), - key_id: (*c.key.key_id.to_str()).clone(), + location: c.key.location.to_str().to_string(), + key_ring_id: c.key.key_ring_id.to_str().to_string(), + key_id: c.key.key_id.to_str().to_string(), key_version: c.key.key_version, },src/models/signer/config.rs (1)
363-364: Prefer header imports over function-level imports.The
use crate::models::SecretString;statement is placed inside the function body. As per the coding guidelines, prefer header imports over function-level imports. Move this import to the top of the file with other imports from thecrate::modelsmodule.🔎 Suggested fix
Remove the function-level import at lines 363-364 and add
SecretStringto the existing import at line 12-20:use crate::{ config::ConfigFileError, models::signer::{ AwsKmsSignerConfig, CdpSignerConfig, GoogleCloudKmsSignerConfig, GoogleCloudKmsSignerKeyConfig, GoogleCloudKmsSignerServiceAccountConfig, LocalSignerConfig, Signer, SignerConfig, TurnkeySignerConfig, VaultSignerConfig, VaultTransitSignerConfig, }, - models::PlainOrEnvValue, + models::{PlainOrEnvValue, SecretString}, };Then remove lines 363-364 from the function body.
src/models/signer/repository.rs (1)
550-682: Consider adding test coverage for GoogleCloudKms storage conversions.The test suite covers
LocalSignerConfig,AwsKmsSignerConfig, andCdpSignerConfigconversions but lacks tests forGoogleCloudKmsSignerConfigStorage. Given the complexity of the config (many SecretString fields, nested structs) and the backwards compatibility requirements mentioned in the PR, a round-trip conversion test similar totest_cdp_config_storage_conversionwould help catch deserialization issues.Would you like me to generate a test case for the GoogleCloudKms storage conversion?
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
src/models/signer/config.rssrc/models/signer/mod.rssrc/models/signer/repository.rssrc/models/signer/request.rssrc/models/signer/response.rssrc/repositories/signer/signer_redis.rssrc/services/google_cloud_kms/mod.rssrc/services/signer/evm/google_cloud_kms_signer.rssrc/services/signer/evm/mod.rssrc/services/signer/solana/mod.rssrc/services/signer/stellar/mod.rssrc/utils/encryption.rssrc/utils/encryption_context.rssrc/utils/mod.rssrc/utils/serde/repository_encryption.rs
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (.cursor/rules/rust_standards.mdc)
**/*.rs: Follow official Rust style guidelines using rustfmt (edition = 2021, max_width = 100)
Follow Rust naming conventions: snake_case for functions/variables, PascalCase for types, SCREAMING_SNAKE_CASE for constants and statics
Order imports alphabetically and group by: std, external crates, local crates
Include relevant doc comments (///) on public functions, structs, and modules. Use comments for 'why', not 'what'. Avoid redundant doc comments
Document lifetime parameters when they're not obvious
Avoid unsafe code unless absolutely necessary; justify its use in comments
Write idiomatic Rust: Prefer Result over panic, use ? operator for error propagation
Avoid unwrap; handle errors explicitly with Result and custom Error types for all async operations
Prefer header imports over function-level imports of dependencies
Prefer borrowing over cloning when possible
Use &str instead of &String for function parameters
Use &[T] instead of &Vec for function parameters
Avoid unnecessary .clone() calls
Use Vec::with_capacity() when size is known in advance
Use explicit lifetimes only when necessary; infer where possible
Always use Tokio runtime for async code. Await futures eagerly; avoid blocking calls in async contexts
Streams: Use futures::StreamExt for processing streams efficiently
Always use serde for JSON serialization/deserialization with #[derive(Serialize, Deserialize)]
Use type aliases for complex types to improve readability
Implement common traits (Debug, Clone, PartialEq) where appropriate, using derive macros when possible
Implement Display for user-facing types
Prefer defining traits when implementing services to make mocking and testing easier
For tests, prefer existing utils for creating mocks instead of duplicating code
Use assert_eq! and assert! macros appropriately
Keep tests minimal, deterministic, and fast
Use tracing for structured logging, e.g., tracing::info! for request and error logs
When optimizing, prefer clarity first, then performance
M...
Files:
src/utils/mod.rssrc/utils/encryption_context.rssrc/repositories/signer/signer_redis.rssrc/utils/serde/repository_encryption.rssrc/models/signer/response.rssrc/services/google_cloud_kms/mod.rssrc/models/signer/request.rssrc/models/signer/config.rssrc/models/signer/repository.rssrc/utils/encryption.rssrc/models/signer/mod.rssrc/services/signer/solana/mod.rssrc/services/signer/stellar/mod.rssrc/services/signer/evm/google_cloud_kms_signer.rssrc/services/signer/evm/mod.rs
🧠 Learnings (3)
📓 Common learnings
Learnt from: sammccord
Repo: OpenZeppelin/openzeppelin-relayer PR: 457
File: src/models/signer/mod.rs:184-203
Timestamp: 2025-09-11T22:32:27.610Z
Learning: SecretString fields in signer configurations do not require explicit serialize_with redaction attributes, as SecretString handles redaction automatically during serialization. Only SecretVec<u8> fields like LocalSignerConfig's raw_key require explicit serialize_with = "serialize_secret_redacted".
📚 Learning: 2025-09-11T22:32:27.610Z
Learnt from: sammccord
Repo: OpenZeppelin/openzeppelin-relayer PR: 457
File: src/models/signer/mod.rs:184-203
Timestamp: 2025-09-11T22:32:27.610Z
Learning: SecretString fields in signer configurations do not require explicit serialize_with redaction attributes, as SecretString handles redaction automatically during serialization. Only SecretVec<u8> fields like LocalSignerConfig's raw_key require explicit serialize_with = "serialize_secret_redacted".
Applied to files:
src/repositories/signer/signer_redis.rssrc/utils/serde/repository_encryption.rssrc/models/signer/response.rssrc/services/google_cloud_kms/mod.rssrc/models/signer/request.rssrc/models/signer/config.rssrc/models/signer/repository.rssrc/models/signer/mod.rssrc/services/signer/solana/mod.rssrc/services/signer/evm/google_cloud_kms_signer.rs
📚 Learning: 2025-11-05T12:25:41.714Z
Learnt from: MCarlomagno
Repo: OpenZeppelin/openzeppelin-relayer PR: 479
File: src/utils/encryption.rs:88-90
Timestamp: 2025-11-05T12:25:41.714Z
Learning: In the openzeppelin-relayer codebase with aes-gcm 0.10, avoid suggesting Key::from_slice() for aes_gcm::Key construction as it generates clippy warnings. The preferred pattern is to use Key::from_iter() with an iterator, e.g., `Key::<Aes256Gcm>::from_iter(key_array.iter().copied())` after validating the key length.
Applied to files:
src/utils/encryption.rs
🧬 Code graph analysis (12)
src/repositories/signer/signer_redis.rs (1)
src/utils/encryption_context.rs (1)
with_aad_sync(82-87)
src/utils/serde/repository_encryption.rs (3)
src/utils/base64.rs (2)
base64_decode(8-10)base64_encode(5-7)src/utils/encryption.rs (5)
decrypt_sensitive_field_auto(399-429)encrypt_sensitive_field_with_aad(373-393)new(63-67)serde_json(353-353)serde_json(414-414)src/utils/encryption_context.rs (2)
get(96-98)with_aad_sync(82-87)
src/services/google_cloud_kms/mod.rs (1)
src/models/secret_string.rs (1)
to_str(72-78)
src/models/signer/request.rs (1)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)
src/models/signer/config.rs (2)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)src/models/secret_string.rs (2)
to_str(72-78)as_str(57-66)
src/models/signer/repository.rs (1)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)
src/utils/encryption.rs (1)
src/utils/base64.rs (2)
base64_encode(5-7)base64_decode(8-10)
src/models/signer/mod.rs (1)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)
src/services/signer/solana/mod.rs (2)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)src/services/signer/solana/google_cloud_kms_signer.rs (1)
new(45-49)
src/services/signer/stellar/mod.rs (1)
src/services/signer/stellar/google_cloud_kms_signer.rs (1)
new(39-43)
src/services/signer/evm/google_cloud_kms_signer.rs (1)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)
src/services/signer/evm/mod.rs (2)
src/services/google_cloud_kms/mod.rs (1)
new(133-157)src/services/signer/evm/google_cloud_kms_signer.rs (1)
new(39-41)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: clippy
- GitHub Check: Unit Tests
- GitHub Check: msrv
- GitHub Check: Properties Tests
🔇 Additional comments (45)
src/utils/mod.rs (1)
44-46: LGTM!The new
encryption_contextmodule is properly declared and re-exported, following the established pattern in this file.src/services/signer/stellar/mod.rs (1)
61-61: LGTM!Boxing
GoogleCloudKmsSignerreduces theStellarSignerenum size and aligns with the consistent pattern applied across EVM, Solana, and Stellar signer modules. The autoderef mechanism ensures method calls continue to work transparently.Also applies to: 158-158
src/services/signer/evm/mod.rs (2)
284-284: LGTM!The boxing of
GoogleCloudKmsSignerin the EVM module is consistent with the pattern applied across all signer modules. Construction and pattern matching are handled correctly.Also applies to: 398-398
731-750: Test properly updated for new types.The test correctly uses
Box::new()for theGoogleCloudKmsvariant andSecretString::new()for all sensitive configuration fields, matching the new type signatures.src/repositories/signer/signer_redis.rs (4)
119-130: AAD-bound deserialization correctly implemented for batch fetch.The deserialization now correctly binds decryption to the storage key using
EncryptionContext::with_aad_sync. This ensures that encrypted data can only be decrypted when associated with its original storage location, protecting against data tampering or key swapping.
195-198: AAD-bound serialization correctly implemented for create.The encryption is properly bound to the storage key, ensuring the ciphertext is authenticated against its storage location.
227-230: AAD-bound deserialization correctly implemented for get_by_id.Consistent with the batch fetch implementation, ensuring authenticated decryption.
288-291: AAD-bound serialization correctly implemented for update.Consistent with the create implementation. Both create and update paths now use the same AAD-bound encryption pattern.
src/services/signer/solana/mod.rs (3)
73-73: LGTM!The boxing of
GoogleCloudKmsSignerin the Solana module is consistent with the pattern applied across all signer modules. The factory method correctly wraps the signer inBox::new().Also applies to: 317-319
460-479: Test properly updated for new types.The test correctly constructs
SignerConfig::GoogleCloudKmswithBox::new()and usesSecretString::new()for all sensitive configuration fields.
582-601: Second test also properly updated.Consistent with the first test, this test correctly uses the new boxed and
SecretString-wrapped types.src/utils/serde/repository_encryption.rs (5)
1-14: Excellent module documentation.The documentation clearly explains the AAD requirements for serialization vs. deserialization, and the backwards compatibility strategy. This is critical for maintainers to understand the encryption migration path.
38-44: Serialization now enforces AAD context.Requiring
EncryptionContextfor serialization ensures all new data is encrypted with AAD binding. The error message is clear and actionable.
59-63: Deserialization supports backwards compatibility.Using
EncryptionContext::get()(optional) withdecrypt_sensitive_field_autoallows decryption of both legacy (v1) and new (v2) data. This is the correct approach for migration.
496-515: Good test coverage for missing context error.This test verifies that serialization fails with a clear error when
EncryptionContextis not set, which is essential for catching configuration issues early.
86-90: Consistent pattern across all serialize/deserialize helpers.The same AAD pattern is correctly applied to
SecretStringandOption<SecretString>variants, maintaining consistency across the module.Also applies to: 116-120, 142-146, 178-182
src/models/signer/config.rs (3)
389-414: LGTM!The conversion logic correctly wraps all sensitive Google Cloud KMS configuration fields in
SecretString, ensuring they will be encrypted at rest. Thekey_versionremains asu32since it's not sensitive.
441-443: LGTM!Boxing
GoogleCloudKmsSignerConfigis a good choice to reduce the size of theSignerConfigenum, as the GCP config contains many fields and wrapping them inSecretStringincreases the struct size.
675-679: LGTM!Test assertions correctly access
SecretStringfields usingto_str().as_str()pattern, which properly extracts the underlying string for comparison.src/utils/encryption_context.rs (3)
22-31: LGTM!The use of
tokio::task_local!is the correct choice for async contexts, ensuring the AAD context follows the task rather than the thread. TheEncryptionContextstruct provides a clean API for setting and retrieving AAD during encryption/decryption operations.
53-87: LGTM!The dual API (
with_aadfor async andwith_aad_syncfor sync) is well-designed. Thewith_aad_syncvariant is particularly useful for serde serializers that need AAD context but run synchronously within an async task.
106-219: LGTM!Excellent test coverage including context propagation, behavior outside scopes, nested context shadowing, and sync/async interop. The tests validate the core invariants of the task-local context mechanism.
src/models/signer/request.rs (2)
178-205: LGTM!The
Fromimplementations correctly wrap all sensitive Google Cloud KMS fields inSecretStringwhen converting from request models to domain models. This ensures sensitive data is protected as soon as it enters the system.Based on learnings, SecretString handles redaction automatically during serialization, so no explicit
serialize_withattributes are needed.
264-269: LGTM!The
SignerConfig::GoogleCloudKmsvariant correctly boxes the configuration, consistent with the domain model changes inmod.rs.src/services/signer/evm/google_cloud_kms_signer.rs (1)
155-178: LGTM!Test configuration correctly uses
SecretStringwrappers for all Google Cloud KMS configuration fields. The test setup properly reflects the updated type definitions.src/utils/encryption.rs (6)
34-37: LGTM!The new error variants
MissingAADandUnsupportedVersionprovide clear, specific error messages for AAD-related failures, improving debuggability.
158-190: LGTM!The
encrypt_with_aadimplementation correctly uses AES-256-GCM with Additional Authenticated Data. ThePayloadstruct properly binds the AAD to the ciphertext, and version 2 is correctly set to distinguish from v1 encrypted data.
192-241: LGTM!The
decrypt_with_aadimplementation correctly requires version 2 and uses the AAD for authenticated decryption. If the AAD doesn't match what was used during encryption, GCM will fail authentication, preventing ciphertext swap attacks.
243-263: LGTM!The
decrypt_automethod provides excellent backwards compatibility:
- Version 1 data decrypts without AAD (legacy support)
- Version 2 data requires AAD, failing clearly with
MissingAADif not provided- Unknown versions are rejected with a specific error
This enables safe migration from v1 to v2 encrypted data.
369-429: LGTM!The high-level functions
encrypt_sensitive_field_with_aadanddecrypt_sensitive_field_autoprovide a clean API that:
- Handles JSON serialization and base64 encoding
- Supports fallback mode when encryption is not configured
- Maintains backwards compatibility with v1 encrypted data
762-786: LGTM!The
test_ciphertext_swap_preventiontest explicitly validates the core security property: encrypted data bound to one AAD cannot be decrypted with a different AAD. This test documents and enforces the protection against ciphertext swap attacks.src/services/google_cloud_kms/mod.rs (4)
132-156: LGTM!The credentials JSON construction correctly extracts string values from
SecretStringfields using.to_str().to_string(). TheZeroizing<String>returned byto_str()ensures sensitive data is zeroed when dropped, and converting toStringfor the JSON is appropriate for the GCP credentials builder.
196-203: LGTM!The
get_base_urlmethod correctly handlesSecretStringby calling.to_str()to get aZeroizing<String>, then dereferencing to access the inner string value. The clone on line 199 is necessary since we need to return an ownedString.
252-261: LGTM!The
get_key_pathmethod correctly uses the deref pattern (*self.config.key.location.to_str()) to access the underlying string values for formatting. This is consistent with theget_base_urlapproach.
535-556: LGTM!The
create_test_confighelper correctly wraps all configuration fields inSecretString, ensuring test configurations match the updated type definitions.src/models/signer/mod.rs (6)
210-266: LGTM!The
GoogleCloudKmsSignerServiceAccountConfigstruct correctly usesSecretStringfor all sensitive fields. The doc comment at lines 211-213 clearly explains the rationale for encrypting these fields at rest in Redis.Each field has appropriate validation:
project_id,client_id,universe_domain: non-empty validation viavalidate_secret_stringauth_uri,token_uri, cert URLs: URL validation viavalidate_secret_url
268-290: LGTM!The
GoogleCloudKmsSignerKeyConfigcorrectly protects key identifiers (location,key_ring_id,key_id) asSecretString. The doc comment at lines 269-271 explains the security rationale: preventing attackers from modifying key identifiers to point to a different key.
309-318: LGTM!The
validate_secret_urlfunction correctly validates that aSecretStringcontains a valid URL. It uses theas_strcallback pattern to safely access the secret content without exposing it, and provides distinct error codes for empty vs. invalid URLs.
383-383: LGTM!The
SignerConfig::GoogleCloudKmsvariant correctly usesBox<GoogleCloudKmsSignerConfig>to reduce enum size, and the validation correctly usesconfig.as_ref()to validate the boxed configuration.Also applies to: 421-421
828-857: LGTM!The
test_valid_google_cloud_kms_signertest correctly constructs the configuration usingBox::newandSecretStringwrappers for all fields. The test validates that proper configuration passes validation.
859-894: LGTM!The
test_invalid_google_cloud_kms_urlstest verifies that URL validation works correctly forSecretStringfields, catching invalid URLs in theauth_urifield.src/models/signer/repository.rs (4)
45-45: LGTM on boxing the GoogleCloudKms variant.Boxing the large nested config struct is appropriate here to avoid bloating the
SignerConfigStorageenum size. The conversion implementations correctly handle the Box indirection.
147-200: Encryption pattern is consistent with existing storage configs.The use of
serialize_secret_string/deserialize_secret_stringfor encryption at rest aligns with the AAD binding approach described in the PR objectives and matches the pattern used by other storage configs in this file (VaultSignerConfigStorage, CdpSignerConfigStorage, etc.).
202-224: Good documentation of the security rationale.The doc comment clearly explains that encryption protects integrity (preventing modification of key identifiers), not just confidentiality. The implementation correctly applies
SecretStringto all string fields while leavingkey_version: u32unencrypted.
467-469: Conversion implementations correctly handle Box indirection.Both
Fromimplementations properly dereference the sourceBox, convert the inner config, and wrap the result in a newBox. The symmetry between the two conversions is correct.Also applies to: 485-487
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
tirumerla
left a comment
tirumerla
left a comment
There was a problem hiding this comment.
lgtm, thanks @NicoMolinaOZ for working on this
There was a problem hiding this comment.
Pull request overview
This PR enhances security for Google Cloud KMS signer configurations by implementing field-level encryption with Additional Authenticated Data (AAD) binding. The changes encrypt all sensitive configuration fields when storing to Redis and bind the encryption to storage keys to prevent tampering and ciphertext swap attacks. The implementation maintains backward compatibility with existing unencrypted and v1 encrypted data.
Changes:
- Added AAD-based encryption infrastructure using task-local context for automatic encryption key binding
- Updated Google Cloud KMS configuration models to encrypt all sensitive string fields including key identifiers
- Enhanced serialization/deserialization utilities to support v1 (legacy) and v2 (AAD-protected) encrypted data with plain text fallback
Reviewed changes
Copilot reviewed 19 out of 21 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/utils/encryption_context.rs | New module providing task-local AAD context for encryption operations |
| src/utils/encryption.rs | Extended encryption utilities with AAD support (v2) and auto-detection for backward compatibility |
| src/utils/serde/repository_encryption.rs | Updated serde helpers to use AAD-based encryption with backward compatibility |
| src/models/signer/mod.rs | Changed Google Cloud KMS config fields from String to SecretString with validation |
| src/models/signer/repository.rs | Added encryption annotations to all Google Cloud KMS sensitive fields |
| src/repositories/signer/signer_redis.rs | Wrapped serialization/deserialization with EncryptionContext for AAD binding |
| src/repositories/api_key/api_key_redis.rs | Wrapped API key operations with EncryptionContext |
| src/services/google_cloud_kms/mod.rs | Updated to extract values from SecretString fields and improved HTTP protocol handling |
| src/utils/url.rs | Fixed typo in comment ("unparseable" → "unparsable") |
| plugins/pnpm-lock.yaml | Formatting changes (whitespace cleanup) |
| openapi.json | Added missing newline at end of file |
| .github/workflows/ci.yaml | Added disk space cleanup step in CI workflow |
Files not reviewed (1)
- plugins/pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
zeljkoX
left a comment
zeljkoX
left a comment
There was a problem hiding this comment.
LGTM
Thanks for working on this one!
Summary
This PR enhances the security of Google Cloud KMS signer configurations stored in Redis by encrypting all sensitive configuration fields and binding encryption to storage keys using Additional Authenticated Data (AAD). By encrypting these fields and binding them to storage keys with AAD, the configuration is now protected both at rest and against tampering.
Testing Process
Checklist
Note
If you are using Relayer in your stack, consider adding your team or organization to our list of Relayer Users in the Wild!
Summary by CodeRabbit
New Features
Security
✏️ Tip: You can customize this high-level summary in your review settings.