Public service interfaces currently expose intermediate transaction-building and signing steps. Callers should only request the actual wallet or Jupiter operation.
Refactor the APIs as follows:
Replace the SOL transaction-building methods on SolanaWallet with high-level operations such as sendSolana(...) and sendAllSolana(...).
Let SolanaWalletImpl coordinate transaction building, signing and submission.
Remove signTransaction(...) from SolanaWallet; signing remains an internal responsibility of the wallet implementation.
Move buildSolanaTransferTransaction(...) and buildSolanaTransferAllTransaction(...) to SolanaBlockChain and its reference implementation.
Keep the binary transaction construction in SolanaBlockChainImpl; do not introduce a separate builder abstraction yet.
Remove these public methods from JupiterPerpsService:
buildPositionIncreaseTransaction(...)
buildPositionDecreaseTransaction(...)
Rename:
executePositionIncreaseTransaction(...) to executePositionIncrease(...)
executePositionDecreaseTransaction(...) to executePositionDecrease(...)
Change the execution methods to receive the wallet and actual position parameters instead of signed transactions.
Let the Jupiter implementation handle transaction building and submission while signing remains the wallet implementation’s responsibility.
Do not introduce a separate signer abstraction yet.
Update the alarm actions to perform their existing safety checks and then use one high-level Jupiter call.
Acceptance criteria
Alarm code no longer builds, signs or submits transactions.
SolanaWallet exposes high-level operations rather than transaction handling.
JupiterPerpsService exposes only complete position operations.
Existing SOL transfer, transfer-all and Jupiter increase/decrease behaviour is preserved.
Public service interfaces currently expose intermediate transaction-building and signing steps. Callers should only request the actual wallet or Jupiter operation.
Refactor the APIs as follows:
* Replace the SOL transaction-building methods on `SolanaWallet` with high-level operations such as `sendSolana(...)` and `sendAllSolana(...)`.
* Let `SolanaWalletImpl` coordinate transaction building, signing and submission.
* Remove `signTransaction(...)` from `SolanaWallet`; signing remains an internal responsibility of the wallet implementation.
* Move `buildSolanaTransferTransaction(...)` and `buildSolanaTransferAllTransaction(...)` to `SolanaBlockChain` and its reference implementation.
* Keep the binary transaction construction in `SolanaBlockChainImpl`; do not introduce a separate builder abstraction yet.
* Remove these public methods from `JupiterPerpsService`:
* `buildPositionIncreaseTransaction(...)`
* `buildPositionDecreaseTransaction(...)`
* Rename:
* `executePositionIncreaseTransaction(...)` to `executePositionIncrease(...)`
* `executePositionDecreaseTransaction(...)` to `executePositionDecrease(...)`
* Change the execution methods to receive the wallet and actual position parameters instead of signed transactions.
* Let the Jupiter implementation handle transaction building and submission while signing remains the wallet implementation’s responsibility.
* Do not introduce a separate signer abstraction yet.
* Update the alarm actions to perform their existing safety checks and then use one high-level Jupiter call.
## Acceptance criteria
* Alarm code no longer builds, signs or submits transactions.
* `SolanaWallet` exposes high-level operations rather than transaction handling.
* `JupiterPerpsService` exposes only complete position operations.
* Existing SOL transfer, transfer-all and Jupiter increase/decrease behaviour is preserved.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Public service interfaces currently expose intermediate transaction-building and signing steps. Callers should only request the actual wallet or Jupiter operation.
Refactor the APIs as follows:
Replace the SOL transaction-building methods on
SolanaWalletwith high-level operations such assendSolana(...)andsendAllSolana(...).Let
SolanaWalletImplcoordinate transaction building, signing and submission.Remove
signTransaction(...)fromSolanaWallet; signing remains an internal responsibility of the wallet implementation.Move
buildSolanaTransferTransaction(...)andbuildSolanaTransferAllTransaction(...)toSolanaBlockChainand its reference implementation.Keep the binary transaction construction in
SolanaBlockChainImpl; do not introduce a separate builder abstraction yet.Remove these public methods from
JupiterPerpsService:buildPositionIncreaseTransaction(...)buildPositionDecreaseTransaction(...)Rename:
executePositionIncreaseTransaction(...)toexecutePositionIncrease(...)executePositionDecreaseTransaction(...)toexecutePositionDecrease(...)Change the execution methods to receive the wallet and actual position parameters instead of signed transactions.
Let the Jupiter implementation handle transaction building and submission while signing remains the wallet implementation’s responsibility.
Do not introduce a separate signer abstraction yet.
Update the alarm actions to perform their existing safety checks and then use one high-level Jupiter call.
Acceptance criteria
SolanaWalletexposes high-level operations rather than transaction handling.JupiterPerpsServiceexposes only complete position operations.