Summary
ContractProvider.generateAuthSignature() generates a fake 64-byte signature and passes it to the Soroban contract's sweep() function. This works today only because the contract's signature verification is also a stub that accepts any input. When the contract's real authorization is implemented in bridgelet-core, this method will start failing silently in ways that are very hard to trace, a sweep will appear to succeed on the SDK side but be rejected on-chain. This issue adds the safeguards that prevent that from happening unnoticed.
Background: The two stubs that depend on each other
There are two authorization stubs that are currently paired:
On the contract side (bridgelet-core), EphemeralAccount.verify_sweep_authorization() accepts any 64-byte value and returns Ok(()) unconditionally. This is documented as a known MVP limitation in the bridgelet-core README.
On the SDK side (ContractProvider), generateAuthSignature() constructs a fake signature by hashing the public key and destination address together, padding the result to 64 bytes, and passing it as if it were a real Ed25519 signature. There is a TODO comment acknowledging this, but no runtime warning, no environment guard, and nothing stopping this from being deployed to a staging or production environment where it would silently undermine the entire authorization model.
What real authorization will look like
When the contract stub is replaced with real verification, the contract will verify the signature against a known authorized public key. The SDK will need to sign a specific message with the corresponding private key. The exact signing scheme will be defined when bridgelet-core implements verify_sweep_authorization. this issue does not implement that. It only makes sure the current stub is clearly marked and cannot silently pass in environments where it should not.
What needs to change
The method needs two things added without changing its current behavior in development:
First, a clear ⚠️ MVP Stub docblock that explains exactly what a real implementation must do, what it must sign, and what the contract will eventually verify against. A future contributor implementing the real version should be able to read this comment and understand the full picture without digging through bridgelet-core.
Second, a runtime environment guard. If the application is running with NODE_ENV set to anything other than development or test, the method should throw or log a loud, unambiguous error rather than returning a fake signature. This ensures the stub cannot reach staging or production unnoticed.
Where to look
- src/modules/sweeps/providers/contract.provider.ts: the file containing generateAuthSignature()
- bridgelet-core/contracts/ephemeral_account/src/lib.rs: the verify_sweep_authorization function this method pairs with
- The bridgelet-core README : the documented MVP limitation this issue mirrors on the SDK side
- src/config/: how NODE_ENV and other environment values are accessed in this project
Acceptance Criteria
Summary
ContractProvider.generateAuthSignature() generates a fake 64-byte signature and passes it to the Soroban contract's sweep() function. This works today only because the contract's signature verification is also a stub that accepts any input. When the contract's real authorization is implemented in bridgelet-core, this method will start failing silently in ways that are very hard to trace, a sweep will appear to succeed on the SDK side but be rejected on-chain. This issue adds the safeguards that prevent that from happening unnoticed.
Background: The two stubs that depend on each other
There are two authorization stubs that are currently paired:
On the contract side (bridgelet-core), EphemeralAccount.verify_sweep_authorization() accepts any 64-byte value and returns Ok(()) unconditionally. This is documented as a known MVP limitation in the bridgelet-core README.
On the SDK side (ContractProvider), generateAuthSignature() constructs a fake signature by hashing the public key and destination address together, padding the result to 64 bytes, and passing it as if it were a real Ed25519 signature. There is a TODO comment acknowledging this, but no runtime warning, no environment guard, and nothing stopping this from being deployed to a staging or production environment where it would silently undermine the entire authorization model.
What real authorization will look like
When the contract stub is replaced with real verification, the contract will verify the signature against a known authorized public key. The SDK will need to sign a specific message with the corresponding private key. The exact signing scheme will be defined when bridgelet-core implements verify_sweep_authorization. this issue does not implement that. It only makes sure the current stub is clearly marked and cannot silently pass in environments where it should not.
What needs to change
The method needs two things added without changing its current behavior in development:⚠️ MVP Stub docblock that explains exactly what a real implementation must do, what it must sign, and what the contract will eventually verify against. A future contributor implementing the real version should be able to read this comment and understand the full picture without digging through bridgelet-core.
First, a clear
Second, a runtime environment guard. If the application is running with NODE_ENV set to anything other than development or test, the method should throw or log a loud, unambiguous error rather than returning a fake signature. This ensures the stub cannot reach staging or production unnoticed.
Where to look
Acceptance Criteria