r35157/com_r35157_nenjim-hubd-impl_ref
0
0
Fork 0
Code Issues 8 Pull Requests Actions Packages Projects Releases Wiki Activity

72: Add the Evelyn IOU buyback-and-burn service

Browse Source
This commit is contained in:
minimons
2026-08-13 16:47:01 +02:00
parent 961f8c69cb
commit 3d5de0e09b
11 changed files with 1790 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/specs/jupiter-swap-service/spec.md
+11 -3
View File
@@ -7,14 +7,22 @@ Defines safe exact-input SPL-token swaps through Jupiter Swap V2 using human-rea
## Requirements
### Requirement: Public exact-input swap contract
The service SHALL accept distinct input and output SPL mint addresses, a positive human-readable input amount, and a maximum slippage in basis points. It SHALL return the confirmed Solana transaction signature together with the actual human-readable input amount spent and output amount received.
The service SHALL accept a positive human-readable exact input amount, a maximum slippage in basis points, a supported output SPL-token mint, and a distinct input representation that is either a supported SPL-token mint or native SOL expressed as the canonical SOL/WSOL mint `So11111111111111111111111111111111111111112`. It SHALL pass that canonical native-SOL representation unchanged to Jupiter as `inputMint`, preserve the existing `swap(...)` signature, and return the confirmed Solana transaction signature together with the actual human-readable input amount spent and output amount received. Callers that select native SOL SHALL remain responsible for identifying the AssetAZ SOL UUID, resolving the canonical mint through CIS, reading native wallet balance, and applying any reserve policy; the swap service SHALL NOT introduce a separate native-SOL operation.
#### Scenario: Successful exact-input swap
- **WHEN** a caller requests a valid exact-input swap that Jupiter executes successfully
- **WHEN** a caller requests a valid exact-input swap from a supported legacy SPL or Token-2022 mint that Jupiter executes successfully
- **THEN** the result contains the confirmed signature and the actual spent and received amounts converted with their respective mint decimal precision
#### Scenario: Successful native SOL input swap
- **WHEN** a caller requests a valid exact-input swap using `So11111111111111111111111111111111111111112` as input and Jupiter executes it from the taker's native SOL balance
- **THEN** Jupiter receives that same canonical input mint and the service returns the confirmed signature and actual human-readable spent and received amounts through the existing result contract
#### Scenario: Existing token-program behavior is preserved
- **WHEN** a caller uses a supported legacy SPL-token or Token-2022 input
- **THEN** mint validation, decimal conversion, signing, single managed execution, and independent `CONFIRMED` handling remain unchanged
#### Scenario: Invalid caller input
- **WHEN** either mint is blank, both mints are equal, the amount is null or non-positive, or the maximum slippage is outside 0 through 10000 basis points
- **WHEN** either mint representation is blank, both mints are equal, the amount is null or non-positive, or the maximum slippage is outside 0 through 10000 basis points
- **THEN** the service rejects the request before requesting a Jupiter order
### Requirement: On-chain mint validation and exact amount conversion