Hyperliquid-kaupankäyntibotin rajapintaintegraatio on enemmän kuin asiakas, joka voi lähettää toimeksiannon. Sen on yksilöitävä aiottu instrumentti, säilytettävä tilikonteksti, sarjallistettava valtuutettu toimi oikein ja tulkittava tulos kadottamatta epävarmuutta näkyvistä. Monet vakavat virheet syntyvät näiden vaiheiden välissä eivätkä itse kaupankäyntisignaalissa.
Opas selittää tuettujen HyperCore-spot-markkinoiden integraation suunnittelua. Perpetual-tuotteet vaativat lisää johdannaiskohtaisia hallintakeinoja, kun taas HyperEVM käyttää EVM-transaktiorajapintaa. Rajapintoja ei pidä yhdistää vain siksi, että ne kuuluvat samaan verkkoon. Meemikolikkostrategia tarvitsee silti varmennetun spot-instrumentin ja riittävän markkinanäytön; rajapintayhteys ei osoita kumpaakaan.
Tekniset tiedot muuttuvat, joten käytä tiettyä toimea toteuttaessasi Hyperliquidin virallisen verkkosivuston kautta löytyvää dokumentaatiota. Seuraava tarkastelu antaa suunnittelukehyksen ja kuvitteellisia esimerkkejä eikä täydellistä allekirjoitustoteutusta tai kehotusta lähettää todellisia toimeksiantoja.
Hyperliquid-kaupankäyntibotin rajapinnan rajat
Julkinen rajapinta erottaa tietopyynnöt allekirjoitetuista kaupankäyntitoimista. Rakenna sovellukseen vastaava raja. Markkinametatietoja hakevalle komponentille ei pidä automaattisesti antaa kaupankäyntivaltuutta, eikä saldoja näyttävän näkymän tarvitse päästä yksityiseen allekirjoitusaineistoon.
Esitä lukutoiminnot ja tilaa muuttavat toiminnot eri kykyinä. Näin havainnointia ja analyysiä voi testata kaupankäyntikyvyn ollessa poissa käytöstä. Sovellus voi myös hylätä odottamattoman toimen ennen sen päätymistä millekään allekirjoittajalle sen sijaan, että se toivoisi myöhemmän rajapinnan kieltäytyvän siitä.
Rajapintasovittimen tulee palauttaa rakenteisia tosiasioita muulle ohjelmalle. Vältä löyhästi tyypitettyä oliota, jota jokainen strategia tulkitsee eri tavoin. Jos yksi komponentti tulkitsee puuttuvan kentän nollaksi ja toinen tuntemattomaksi, sama vastaus voi valtuuttaa ristiriitaiset päätökset.
Selvitä omaisuuserän oikea esitystapa
HyperCoren spot-tokenien tunnisteet, paritunnisteet ja toimeksiantotoimessa käytetty omaisuuserätunniste eivät ole keskenään vaihdettavissa. Selvitä valitun ympäristön nykyiset metatiedot ja säilytä ehdotuksen käyttämä vastaavuuskartoitus. Dokumentaation numeroesimerkin kopiointi eri markkinaan tai ympäristöön ei ole luotettava tunnistusmenetelmä.
Tyypitetty sisäinen markkinatietue voi sisältää luettavan symbolin, perusvaran, noteerausvaran, ympäristön ja toteutustunnisteen erillään. Tämä estää käyttöliittymän nimikettä muuttumasta vahingossa toteutusargumentiksi. Se helpottaa myös rakennemuutosten havaitsemista, koska jokaisella kentällä on määritelty tarkoitus.
Omaisuuserien identiteettiviite tarjoaa hyödyllisen käsitteellisen perustan. Anna integraatiotestissä tarkoituksella token-tunniste kohtaan, jossa odotetaan paritunnistetta, ja varmista sovelluksen hylkäävän ristiriidan. Vain yhtä tunnettua omaisuuserää käyttävä testi ei ehkä koskaan paljasta tätä virheluokkaa.
Pidä tilin ja allekirjoittajan identiteetit erillään
Tili, jonka saldoja luetaan, voi erota rajapinta-agentista, joka allekirjoittaa sille sallittuja toimia. Nykyinen dokumentaatio erottaa nämä roolit nimenomaisesti. Mallinna ne erillisiksi kentiksi sen sijaan, että yksi wallet-niminen muuttuja tarkoittaisi molempia kaikkialla.
Varmenna myös tilitila. Yhdistetyillä tileillä ja salkkumarginaalitileillä dokumentoitu spotClearinghouseState-vastaus edustaa kaupankäyntisaldoja spot- ja perpetual-tuotteista. Spot-painotteisen strategian on silti huomioitava näiden tuotteiden soveltuvat sitoumukset käytettävissä olevia resursseja arvioidessaan.
Erottelu on tärkeä vianmäärityksessä. Tilitiedustelun tyhjä tulos voi johtua väärän osoitteen valinnasta. Sen ei pidä välittömästi laukaista rahoitusohjetta tai saldon nollausta. Selvitä ensin pyydetty tili ja vastaako se valtuutetussa kaupankäyntiaikomuksessa nimettyä tiliä.
Käytä nimenomaista kontekstia alatilejä tai muita tuettuja tilijärjestelyjä käsitellessäsi. Kutsujan tulee ilmoittaa kohdetili, kun taas allekirjoittajarekisteri määrittää kontekstiin hyväksytyt valtuudet. Älä anna oletustilin korvata hiljaa puuttuvaa tilikenttää tilaa muuttavassa pyynnössä.
Käsittele allekirjoitusta protokollatoteutuksena
Allekirjoitusviite kuvaa useampaa kuin yhtä allekirjoitusmenetelmää ja korostaa sarjallistamisen yksityiskohtia. Allekirjoitus, josta allekirjoittaja voidaan palauttaa paikallisesti, ei yksin todista etäpalvelun tulkitsevan aiotun tietosisällön oikein. Toteutuksen on vastattava todellista toimintamuotoa, ympäristöä ja kanonista esitystä.
Käytä arvioitua, versioitua allekirjoituskoodia ja testaa sitä tunnetuilla testiaineistoilla. Pidä allekirjoittamaton kanoninen tietosisältö tarkasteltavana muodossa, joka ei sisällä salaisuuksia. Testiaineiston tulee näyttää allekirjoitetut julkiset kentät ja se, miten yhden kentän muutos muuttaa valtuutettavaa viestiä.
Älä selvitä virheitä tulostamalla yksityisavaimia, palautuslauseita tai salaisuuksia sisältäviä olioita. Virheisiin voi sisällyttää julkisia tilitunnisteita, toimintoluokkia ja turvallisen korrelaatiotunnisteen. Diagnostiikkatulosteen tarkoitus on selittää ristiriita eikä jäljentää allekirjoitusvaltuutta jokaiseen lokikohteeseen.
Koordinoi nonce-arvot allekirjoitusvallan mukaan
HyperCore-toimien nonce-arvot eivät noudata tavallista Ethereumin peräkkäisten transaktiononcejen mallia. Integraation tulee käyttää dokumentoituja allekirjoittajakohtaisia sääntöjä ja koordinoida kaikki saman allekirjoitusidentiteetin jakavat prosessit. Erilliset strategiat eivät ole riippumattomia nonce-alueita vain siksi, että niiden asetukset näkyvät eri näkymissä.
Pysyvä nonce-koordinaattori voi tarjota yhden jakopolun valtuutetuille toimille. Testaa samanaikaiset pyynnöt, prosessien uudelleenkäynnistykset ja kellomuutokset. Koordinaattorin tulee estää tahaton uudelleenkäyttö olettamatta järjestelmäkellon aina etenevän tasaisesti tai pyyntöjen saapuvan luontijärjestyksessään.
Agentin elinkaari ansaitsee oman menettelynsä. Virallinen ohje varoittaa rekisteristä poistettujen agenttiosoitteiden uudelleenkäytöstä sen jälkeen, kun niiden nonce-tila voidaan karsia. Käsittele todentamistietojen vaihtoa hallittuna muutoksena uusine valtuuksineen ja täsmäytyksineen eikä mahdollisuutena käyttää vanhoja allekirjoitettuja viestejä uudelleen.
Säilytä desimaalien tarkoitettu arvo
Hinnat ja määrät tarvitsevat markkinakohtaisen tarkkuuden. Binäärinen liukulukulaskenta voi muuttaa desimaaliarvon ennen sarjallistamista, joten käytä tarkkaa esitystapaa arvoille, joiden tarkkuus vaikuttaa valtuutukseen. Käyttäjän tai säännön arvioiman arvon tulee olla sama kuin allekirjoituskerrokselle välitetty arvo.
Pyöristys on päätös eikä muotoilun jälkiajatus. Ostomäärän pyöristäminen ylöspäin voi kasvattaa menoa. Rajahinnan pyöristäminen epäedulliseen suuntaan voi muuttaa hyväksyttyä enimmäiskulua. Määritä sallittu suunta ja tarkista muodostuva määrä strategian rajaa vasten uudelleen pyöristyksen jälkeen.
Havainnollistava määrä 12,3456 pyöristyy alaspäin arvoon 12,34 sallitun askelen ollessa 0,01. Tuloksen sallittavuus riippuu silti valitun markkinan muista rajoituksista. Yhden tarkkuustarkistuksen läpäisy ei todista koko toimeksiannon olevan kelvollinen tai taloudellisesti sopiva.
Hyperliquid-bottirajapinnan toimeksiantojen käsittely
Hyperliquid-bottirajapinnan toimeksiantokäsittelyn tulee erottaa tiedonsiirtovastaukset yksittäisten toimien tuloksista. Normaali HTTP-vastaus voi sisältää toimeksiantotason hylkäyksen, ja hyväksytty toimeksianto voi jäädä avoimeksi täyden toteutumisen sijaan. Yhtenäistä erot tiloiksi, joita strategia voi käyttää johdonmukaisesti.
Säilytä aiotun toimen tunniste, mahdollinen asiakkaan toimeksiantotunniste, palautettu toimeksiantoidentiteetti ja havaittu tulos. Niillä on eri tehtävät. Asiakkaan luoma tunniste auttaa työn yhdistämisessä, mutta sen olemassaolo ei poista tarvetta kysellä ja täsmäyttää epävarmaa tulosta rajapinnan todellisten merkitysten mukaan.
Automaattisen järjestelmän käyttöopas selittää epävarmuuden oman varsinaisen tilan tarpeen. Vältä koodipolkuja, joissa jokainen poikkeus muuttuu epäonnistumiseksi ja jokainen poikkeukseton tulos valmistuneeksi. Ensimmäinen oikotie voi luoda päällekkäisiä toimia ja toinen peittää toteutumattomat sitoumukset.
Validoi koko pyyntö ennen lähettämistä
Pyyntövalidaattorin tulee tutkia koko konteksti: ympäristö, tili, instrumentti, toimintotyyppi, tarkkuus, koko, hintaehto, budjetti ja käyttöoikeus. Yksittäisten kenttien validointi on tarpeen mutta ei riitä. Kaksi kelvollista kenttää voi silti muodostaa virheellisen yhdistelmän, kuten yhden ympäristön tunniste ja toiseen määritetty allekirjoittaja.
Tuota tällä rajalla hyödylliset hylkäyssyyt. ”Instrumenttia ei tueta valitussa ympäristössä” kertoo enemmän toiminnan suunnasta kuin myöhemmin löytyvä yleinen rajapintavirhe. Pidä toimintakäytännön hylkäys erillään virheellisestä datasta, jotta seuranta erottaa normaalin strategiakurin integraatiovioista.
Validaattorin tulee myös hylätä tuntemattomat toimintokentät sovelluksen odottaessa kiinteää rakennetta. Mielivaltaisten lisäkenttien hiljainen välittäminen vaikeuttaa päivitysten ja epäluotettujen syötteiden hallintaa. Arvioi uudet tuetut kentät harkiten, myös muuttavatko ne maksuja, valtuuksia tai aiemman toimeksiannon merkitystä.
Mallinna erät kadottamatta yksittäisiä tuloksia
Eräkäsittely voi vähentää viestintäkuormaa, mutta se ei oikeuta käsittelemään kaikkia sisältyviä toimia yhtenä erottelemattomana tuloksena. Säilytä kunkin pyydetyn toimen indeksi tai identiteetti ja yhdistä jokainen vastaus oikeaan aikomukseen. Erän osittainen epäonnistuminen ei saa johtaa jo hyväksytyn työn sokeaan uudelleenluontiin.
Testaa epätavallisia yhdistelmiä, kuten yksi kelvollinen toimi, yksi tarkkuusvirhe ja yksi toimintarajoitukseen kaatuva toimi. Sovelluksen tulee ymmärtää, hylkäsikö rajapinta koko erän vai palauttiko se erilliset tulokset. Käyttäytymisen on perustuttava dokumentoituun rakenteeseen ja havaittuun testinäyttöön eikä oletukseen.
Sama kuri koskee peruutuseriä. Useiden toimeksiantojen peruminen ei todista, ettei yksikään toteutunut ennen peruutusta. Täsmäytä jokainen toimeksianto ja sen toteumat ennen omistuksen päivittämistä tai koko varatun kapasiteetin vapauttamista.
Suosittele ja ansaitse USDC:tä
Suosittele ja ansaitse USDC:täKumppaniohjelmamme maksaa reaaliajassa.
Palaudu kadonneesta vastauksesta
Lähetyksen jälkeinen aikakatko luo tieto-ongelman. Etäjärjestelmä on saattanut hyväksyä toimen, vaikka asiakas ei saanut tulosta. Palautumisrutiinin tulee tutkia tallennettua aikomusta ja saatavilla olevaa toimeksiantonäyttöä ennen uuden toimen sopivuuden ratkaisemista.
Yksi kuvitteellinen vikatesti voi pysäyttää asiakkaan heti pyynnön poistuttua prosessista. Uudelleenkäynnistyksessä järjestelmän tulee löytää lähetettävänä oleva aikomus, säilyttää sen resurssivaraus ja siirtyä täsmäytykseen. Sen ei pidä palauttaa aikomusta koskaan yrittämättömäksi vain siksi, ettei vastausta kirjattu.
Määritä, kuinka kauan selvittämätön työ saa pysyä tässä tilassa ja mitä se estää. Rajattu jatkokäsittelypolku on parempi kuin loputon hiljainen odotus tai välittömät uusinnat. Käyttäjä tarvitsee riittävät tiedot erottaakseen tilapäisen havaintoviiveen pysyvästä, tutkimusta vaativasta ristiriidasta.
Palauta tietovirrat tilasuunnitelman avulla
WebSocket-tilaus on tiedonsiirtomekanismi eikä pysyvä takuu paikallisen tilinäkymän täydellisyydestä. Uudelleenyhdistäminen voi sisältää alkutilannekuvia, uusia tapahtumia ja puuttuvia aikavälejä. Päätä kanavan dokumentoitujen merkitysten perusteella, miten havainnot yhdistetään kahdentamatta toteumia tai hukkaamatta muutoksia.
Pidä vastaanotettu viesti ja sovellettu tilasiirtymä selvästi erillään. Saman tapahtuman havaitseminen uudelleen ja soveltaminen kahdesti voisi kahdentaa raportoidun omistuksen tai kulut. Vakaat tapahtumatunnisteet ja pysyvä soveltamistietue auttavat tekemään toistosta turvallisen.
Yhteyden elossaoloviesti voi osoittaa yhteyden pysyvän aktiivisena samalla kun tietyn markkinan päivitykset lakkaavat. Seuraa tuoreutta olennaisen tietovirran mukaan äläkä vain socket-yhteyden aktiivisuutta. Strategian tulee tietää, ovatko sen tarjouskirja-, tili- ja toteutushavainnot riittävän ajantasaisia aiottuihin käyttötarkoituksiinsa.
Varaudu rajalliseen historiaan
Rajapintavastaus voi palauttaa rajatun joukon viimeaikaisia tietueita kattavan tilihistorian sijaan. Suunnittele tiedon vastaanotto dokumentoitujen sivutus- ja säilytysrajojen mukaan. Vastausta, jossa ei ole lisäkohteita, ei pidä automaattisesti tulkita todisteeksi koko vanhemman jakson rekonstruoinnista.
Tallenna paikalliseen täsmäytykseen ja arviointiin tarvittava historia sen saapuessa. Kirjaa kattavuusrajat ja aukot selvästi. Jos myöhempi palautuminen ei pysty hakemaan puuttuvaa väliä, raportin tulee yksilöidä aukko eikä täyttää sitä nollatoiminnalla.
Esimerkiksi tilin saldoero voi selittyä saatavilla olevan toteumahistorian ulkopuolisella siirrolla. Oikea johtopäätös on lisänäytön tarve. Keinotekoisen kaupan luominen kirjanpidon pakottamiseksi tasapainoon saastuttaisi sekä toimintatietueet että myöhemmän strategia-arvioinnin.
Varaa pyyntöbudjetti
Pyyntörajoitukset voivat päteä useilla tasoilla ja eri painoilla. Rakenna budjetti markkinakyselyjen, tililukujen, tilausten ja allekirjoitettujen toimien todelliselle yhdistelmälle. Yksi pyyntöä sekunnissa -arvio tuskin kuvaa kaikkia olennaisia rajoituksia tai pyyntöpiikkejä.
Priorisoi palautuminen ja tilitietoisuus valinnaisten näyttöjen edelle. Sovelluksen lähestyessä rajaa turhien markkinapäivitysten vähentäminen voi säilyttää kapasiteetin selvittämättömän toimen tutkimiseen. Eksponentiaalinen uusintasilmukka ilman yleistä budjettia voi pahentaa alkuperäistä katkoa kuluttamalla palautumiseen tarvittavan kapasiteetin.
Mittaa todelliset kutsumäärät ja virheluokat testauksen aikana. Rajapintasuunnittelun opas käsittelee yleistä pyyntöbudjetointia ja näytön keruuta; säilytä kohdeverkon omat menetelmät ja rajat. Verkkojen väliset suunnitteluideat voivat siirtyä, mutta numerokiintiöt ja vastausrakenteet yleensä eivät.
Erota rajapintavirheet strategian hylkäyksistä
Strategian sallitun hinta-alueen ulkopuolinen hinta ei ole palvelukatko. Virheellinen allekirjoitus ei ole heikko kaupankäyntisignaali. Hyvin järjestetty virheluokittelu pitää nämä epäonnistumiset erillään, jotta käyttäjä voi vastata todelliseen ongelmaan.
Hyödyllisiä luokkia ovat paikallinen validointi, valtuutus, tiedonsiirto, etäpalvelun rakenne, toimeksiannon hylkäys ja täsmäytysristiriita. Kullakin voi olla eri uusintakäytäntö. Lukupyyntöä voi uusia hidastuksella, kun taas valtuuttamattoman toimen tulee pysyä estettynä, kunnes taustalla oleva oikeus tai pyyntö muuttuu.
Vältä rajojen automaattista löysentämistä toistuvien epäonnistumisten jälkeen. Jos toimeksianto rikkoo toistuvasti hintaehtoa, toleranssin kasvattaminen muuttaa strategian taloudellista toimintaa. Päätös kuuluu arvioituun käytäntöpäivitykseen eikä yleiseen poikkeuskäsittelyyn, jonka tarkoitus on pitää ohjelma käynnissä.
Hyperliquid-kaupankäyntibotin rajapinnan testaus
Hyperliquid-bottirajapinnan testauksen tulee sisältää rakenteiden sopimustestit, deterministiset allekirjoitustestiaineistot, simuloidut tilisiirtymät ja hallitut ympäristötarkistukset. Jokainen kerros vastaa eri kysymykseen. Rakennetestiaineisto voi osoittaa jäsennyksen käsittelevän kentän; se ei voi todistaa tulevan todellisen toimeksiannon toteutuvan.
Käytä tarkoituksella virheellisiä ja epätäydellisiä esimerkkejä onnistuneiden vastausten rinnalla. Poista vaadittu identiteettikenttä, muuta desimaaliesitystä, kahdenna tapahtuma ja palauta tuntematon tila. Sovittimen tulee epäonnistua selvästi tai säilyttää epävarmuus eikä hiljaa muuntaa jokaista uutta arvoa onnistumiseksi.
Pidä testivaltuudet eristettyinä. Vain jäsennystä ja strategia-arviointia tarvitseva testisarja ei saa sisältää allekirjoituskykyä. Merkitse ympäristökohtaisen integraation testi nimenomaisesti ja estä asetusten varavaihtoehtoa vaihtamasta toiseen ympäristöön pyydetyn palvelun ollessa poissa käytöstä.
Testaa peruutusta muuttuvalla tilillä
Peruutus on erityisen hyödyllinen kilpailutilanteiden testauksessa, koska toimeksianto voi muuttua pyynnön kulkiessa. Kuvitellaan 60 tokenin toimeksianto. Asiakas näki viimeksi 20 toteutuneena ja pyytää sitten peruutusta. Ennen pyynnön voimaantuloa vielä 10 toteutuu. Lopullinen positio on 30 tokenia, vaikka peruutus itsessään onnistuu jäljellä olevalle määrälle.
Testin tulee siksi tarkistaa sekä lopullinen toimeksiantotila että lopullinen omistus. Pelkkä peruutusmenetelmän normaali palautuminen jättää taloudellisen tuloksen tarkistamatta. Säilytä ennen peruutusvastausta, sen aikana ja sen jälkeen saapuvat toteumat ja anna täsmäytyksen selvittää koko havaittu tulos. Asiakasilmoitusten järjestys voi erota markkinatapahtumien järjestyksestä.
Erota peruutus myös myyntiohjeesta. Ostositoumuksen poistaminen ei luovuta jo hankittuja tokeneita. Molemmat samaan nimikkeeseen yhdistävä palautumisnäkymä voi saada käyttäjän luulemaan altistuksen kadonneen, vaikka vain tuleva toteutus on pysäytetty.
Perpetual-position sulkemisen palautumisesimerkki soveltaa samaa kilpailutilanteen arviointia vain positiota pienentävään ohjeeseen, jossa lopullinen johdannaispositio on selvitettävä ennen seuraavan sulkemisen mitoittamista.
Tee diagnostiikkatietueista hyödyllisiä ilman salaisuuksia
Hyvä diagnostiikkatietue sisältää toimintoluokan, turvallisen tiliviitteen, ympäristön, instrumentti-identiteetin, korrelaatiotunnisteen, aikaleimat ja yhtenäistetyn tuloksen. Sen tulee selittää epäonnistunut vaihe ja onko taloudellinen vaikutus edelleen mahdollinen. Tiedot voidaan kerätä tallentamatta toimia valtuuttavaa yksityistä aineistoa.
Salaiset tiedot on peitettävä ennen datan päätymistä yhteiseen lokipalveluun, kaatumisraporttiin tai tukiliitteeseen. Pelkän käyttäjänäkymän suodattaminen jättää muut kopiot koskemattomiksi. Testaa diagnostiikkapolku tunnistettavilla valesalaisuuksilla ja varmista, ettei merkkijonoja koskaan esiinny viedyissä tietueissa. Tämä on hyödyllinen turvallisuustarkistus, koska se mittaa todellista tietovirtaa eikä oleta muuttujanimen takaavan salaisuutta.
Myös säilytys on tärkeä. Pidä riittävästi näyttöä selvittämättömän työn tutkimiseen ja toiminnallisen luotettavuuden arviointiin, mutta vältä jokaisen tietosisällön kopioimista määräämättömäksi ajaksi ilman tarkoitusta. Julkiset transaktio- ja toimeksiantotunnisteetkin voivat paljastaa tilitoimintaa. Viennin tulee olla harkittu, ymmärrettävä ja rajattu tukemaansa tutkimukseen.
Versioi sovitin ja sen näyttö
Asiakaskirjaston, vastausrakenteen tai allekirjoitusrutiinin muutokset voivat muuttaa toimintaa kaupankäyntistrategiasta riippumatta. Kirjaa sovitinversiot strategiaversioiden rinnalle toimintapäiväkirjaan. Näin voidaan tunnistaa, alkoiko uusi virhe infrastruktuurimuutoksen eikä markkinamuutoksen jälkeen.
Arvioi päivitykset tallennettuja edustavia vastauksia ja epäedullisia tapauksia vasten. Lisää uusi testiaineisto häiriön paljastaessa käsittelemättömän ehdon ja varmista korjauksen säilyttävän aiemman odotetun toiminnan. Vältä testejä, jotka vain toistavat toteutusyksityiskohtia tarkistamatta merkityksellistä tili- tai toimintotulosta.
Hyperliquid-bottirajapinnan integraatio on valmis vain käytännöllisessä mielessä: sen tuetut toiminnot on määritelty ja testattu ja tukemattomat tapaukset näkyvät. Hyödyllisin suunnittelusaavutus ei ole onnistunut ensimmäinen pyyntö. Se on johdonmukainen näyttöketju, joka yhdistää aiotun toimen, käytetyn valtuuden, etäpalvelun tuloksen ja sitä seuraavan tilin tilan.