ID d'ordre réel à propager côté agent d'exécution, backend et receipt.
SterlingChain
STRL core unit · internal gas · L1 exchange routes
SterlingChainSterlingDEXSTRLRFQ
Exécution RFQ / API desks
Endpoints RFQ, surface de signature 1492 et champs utiles pour l'exécution dans un même dossier lisible.
Cette page explique comment un agent d'exécution RFQ, un desk quantitatif type Wall Street ou un système de paiement réel lit le carnet T4, soumet sa signature de paiement et utilise 8012, 8000 et 1492 sans ambiguïté.
Kit d'exécution RFQ
Clients téléchargeables pour quants, desks API et systèmes de paiement réel.
Les clients publiés lisent le carnet, récupèrent le ticket actif, construisent le claim 1492 et laissent chaque agent d'exécution signer le paiement USDC/SOL avec son propre wallet.
Python
DISPONIBLEsterling-rfq-bot-client.py
Client Python minimal pour discovery RFQ, claim 1492 et dry-run de signature.
OuvrirTypeScript
DISPONIBLEsterling-rfq-bot-client.ts
Référence Node/TypeScript pour brancher un agent d'exécution sans reverse engineering.
OuvrirOpenAPI
DISPONIBLEopenapi.json
Schema public des routes RFQ, lisible par generateurs client et tests CI.
OuvrirExecution tooling
DISPONIBLEpostman_collection.json + Hummingbot
Pack d'integration rapide avec collection Postman standard et squelette Hummingbot telechargeable.
OuvrirTicket actif
Ticket 000001 / 4200 ouvert sur la surface d'exécution RFQ.
Le carnet T4 publie des tickets à $2,500,000 de notionnel, vendus $2,475,000 avec discount net pur. Les remplissages partiels restent publics et lisibles pour les agents d'exécution: 250 · 1k · 25k · 250k · 1M · 2.5M.
ID de tranche séquentiel du registre L3, utilisé au moment de la vérification.
USDC reste prioritaire. SOL reste le rail natif secondaire exposé aux desks API et systèmes de paiement réel.
Lecture
Trois surfaces de lecture, une seule vérité métier.
Les agents d'exécution peuvent découvrir les tickets via le miroir public, lire le registre backend direct, puis confirmer la même tranche via la surface native 1492 si nécessaire.
8012 public mirror
DISPONIBLEwww.sterlingchain.net/api/v1/rfq/market-tickets
Lecture publique canonique du carnet RFQ, consommable directement depuis sterlingchain.net.
Ouvrir8000 registry
DISPONIBLEapi.sterlingchain.net/api/v1/rfq/market-tickets
Lecture backend directe du registre RFQ avec les mêmes order_id, tranche_id et montants.
Ouvrir1492 native
DISPONIBLEwww.sterlingchain.net/rfq-native/market-tickets.json
Lecture native 1492 exposée publiquement par proxy, utile pour confirmer la même tranche sur la surface d'autorité.
OuvrirSignature
La soumission de paiement part vers 1492 en priorité.
Un agent d'exécution lit le carnet, paie la tranche avec argent réel, puis soumet la signature Solana sur la surface native. Le backend 8000 reste disponible comme fallback de vérification, mais la préférence publique reste 1492.
1492 preferred
DISPONIBLEwww.sterlingchain.net/rfq-native/settlement/verify-payment
Surface native prioritaire pour soumettre la signature de paiement et enclencher le receipt 1492.
Ouvrir1492 claim
DISPONIBLEwww.sterlingchain.net/rfq-native/atomic-claim-ticket
Construit une transaction USDC + memo pré-signée par le paymaster, sans transfert SPL sortant Sterling.
Ouvrir8000 fallback
DISPONIBLEapi.sterlingchain.net/api/v1/rfq/settlement/verify-payment
Fallback public si la surface native n'est pas disponible au moment du submit.
OuvrirPaiement réel vérifié, receipt 1492 écrit et lisible en vert.
La surface verify-payment montre maintenant une preuve réelle: paiement SOL reçu, discount 1% NET, signature L1 vérifiée et receipt 1492 écrit. Le wallet de règlement crédité est CMqD45Kq5o...71CzCeTw. Le gas proof public du Paymaster reste publié sur BdyczRRxau...MEL5ZBHY.
StatutSELF_BUY_TEST_SETTLED
Face value$5.30
Paiement demandé0.05597 SOL
Principal reçu0.05599 SOL
Discount1% NET
Sponsoring gaz déclaréOui
Signature L1 vérifiée
2t8Av1oWkS8zWcVPN9ycQMfBQ2gKXnwgoGjn3tDsh9Et9t9u4SfZhj2RKmnKiLtWi6c5ZHMDGWBaGUBruadSTwABReceipt 1492 réel
rfq_f987478e5f3d2403539b6601Fee payer observéCMqD45Kq5o...71CzCeTw
Argent envoyé versCMqD45Kq5o...71CzCeTw
RailSOL
Montant attendu0.05597 SOL
Paymaster gas proof publié
BdyczRRxauAewNr91twqQm75PKmvQ485Upp1MEL5ZBHYCompte de règlement crédité
CMqD45Kq5oukPvaMDhzav5RxJqZb1xME1MmV71CzCeTwFee payer observé dans ce règlement
CMqD45Kq5oukPvaMDhzav5RxJqZb1xME1MmV71CzCeTwVert veut dire paiement L1 vérifié et receipt 1492 écrit.
Cette preuve ne repose plus sur un exemple inventé. Le principal SOL a été reçu sur le wallet de règlement publié, la signature L1 a été vérifiée, puis 1492 a écrit le receipt interne. Le Paymaster gas proof public reste séparé du fee payer observé dans ce règlement précis.
order_idrfq_selfbuy_5p3usd_1492
tranche_idfee_claim_tranche_selfbuy_000530
Signature L12t8Av1oWkS...uadSTwAB
Receipt 1492rfq_f98747...539b6601
Montant reçu0.05599 SOL
DestinationCMqD45Kq5o...71CzCeTw
Adresse Paymaster gas proof
BdyczRRxauAewNr91twqQm75PKmvQ485Upp1MEL5ZBHYAdresse de règlement réelle
CMqD45Kq5oukPvaMDhzav5RxJqZb1xME1MmV71CzCeTwAdresse fee payer observée
CMqD45Kq5oukPvaMDhzav5RxJqZb1xME1MmV71CzCeTwJSON fields
Les champs à parser côté exécution sont figés et lisibles.
La règle simple: lire l'identité du ticket, le montant payé, le notionnel reçu, les tailles de fill autorisées et le rail préféré. Pas de bonus artificiel à interpréter.
order_id
ID ordre lisible par agent d'exécution, unique pour chaque ticket ou sous-tranche.
tranche_id
ID tranche séquentiel dans le registre L3.
ticket_label
Label humain du ticket, ex: Ticket 000001 / 4200.
robot_pays_usd | bot_price_usd
Montant réellement payé par l'agent d'exécution selon la surface lue.
nominal_value_usd | size_usd
Valeur notionnelle reçue par l'agent d'exécution.
accepted_child_tranches
Paliers de remplissage autorisés: 250 / 1k / 25k / 250k / 1M / 2.5M.
preferred_payment_rail
Rail de paiement prioritaire. La vérité courante reste USDC puis SOL.
signature_status
Statut d'exécution attendu avant release et receipt 1492.
Ordre backend
Ordre d'utilisation recommandé pour desks quantitatifs et agents de paiement réel.
Un système d'exécution n'a pas besoin de deviner la topologie: lecture publique d'abord, registre ensuite, puis signature native 1492 au moment du règlement.
1. Lire d'abord le miroir public 8012 sur sterlingchain.net pour la découverte rapide.
2. Lire ensuite le registre 8000 si l'agent veut une lecture backend directe.
3. Lire 1492 en natif si l'agent veut confirmer la même tranche sur la surface d'autorité.
1. Construire le claim atomique sponsorisé via la surface native 1492 si le desk veut un flux USDC + memo pré-signé.
2. Soumettre la signature de paiement sur la surface native 1492.
3. Utiliser 8000 seulement comme fallback de vérification si 1492 n'est pas disponible.
Exemples
Commandes minimales pour lire et soumettre.
Cette page garde aussi les commandes courtes pour les desks et les intégrateurs qui veulent brancher un agent d'exécution sans reverse engineering.
Miroir public 8012
curl
curl -s 'https://www.sterlingchain.net/api/v1/rfq/market-tickets'
Surface 1492 proxyfiée
curl
curl -s 'https://www.sterlingchain.net/rfq-native/current-sellable-ticket.json'
POST verify-payment
curl
curl -s -X POST 'https://www.sterlingchain.net/rfq-native/settlement/verify-payment' -H 'Content-Type: application/json' -d '{"order_id":"rfq_million_xxx","tranche_id":"fee_claim_tranche_000001","tx_hash":"<solana_signature>"}'POST atomic-claim-ticket
curl
curl -s -X POST 'https://www.sterlingchain.net/rfq-native/atomic-claim-ticket' -H 'Content-Type: application/json' -d '{"bot_wallet":"<bot_solana_wallet>","order_id":"rfq_million_xxx","tranche_id":"fee_claim_tranche_000001","fill_usd":"250"}'Manifest public exécution / dev
Le manifeste résume les endpoints, l'ordre des backends, les champs requis et les exemples de submit pour desks API et agents quantitatifs.
Le guide complète Gateway et Integrators
La page humaine raconte exactement la même chose que le JSON machine-readable, sans divergence entre 8012, 8000 et 1492.