Kaupankäynti Polymarketin API:lla yhdistää kaupankäyntipäätöksen pyyntöjen, toimeksiantotilojen, kauppatietueiden ja tilimuutosten ketjuun. Hyödyllinen ymmärtämisen yksikkö on todennetun toimeksiannon elinkaari. Pyynnön onnistuneesti lähettänyt ohjelma on suorittanut vain osan työstä: sen on vielä selvitettävä, mitä tapahtui ja mitä altistusta on jäljellä.

Opas koskee kansainvälisen Polymarketin API-ympäristöä. Polymarket US:llä on erillinen kauppapaikka- ja tiliympäristö, joten sen rajapinnat ja käyttöoikeudet tulee tarkastaa erikseen. Myös ajantasaisilla ohjeilla on merkitystä: lompakkojärjestelyt, asiakaskirjastot ja vakuuksien yksityiskohdat voivat muuttua, jolloin vanha esimerkki ei ole luotettava määrittely uudelle integraatiolle.

Alla oleva skenaario selittää elinkaarta keksityillä hinnoilla, määrillä ja maksuilla. Se ei toteuta kauppaa eikä määrää sijoitusta. Suunnitteluperiaatteet soveltuvat käsin tehtävään tarkastukseen, valvottuihin työkaluihin ja valtuutettuihin automatisoituihin työnkulkuihin siten, että tilinomistaja säilyttää määräysvallan ohjelman sallittuihin toimiin.

Aloita kaupankäynti Polymarketin API:lla sopimustietueesta

Ensimmäisen tietueen tulee yksilöidä todellinen instrumentti. Säilytä markkina, tulostoken, valittu puoli, täydelliset säännöt ja olennaiset määräajat. Pelkkä otsikko ei erota luotettavasti samannimisiä sopimuksia, ja ihmistarkastajan on vaikea varmentaa tokenin tunnistetta ilman sen merkitystä.

Kuvittele keksitty binäärimarkkina siitä, myönnetäänkö lupa tiettyyn päivään mennessä. Tarkoituksena on ostaa juuri tämän kysymyksen Kyllä-tulos. Tähän liittyvä markkina rakentamisen myöhemmästä aloittamisesta on eri instrumentti, vaikka otsikoissa olisi enimmäkseen samat sanat.

Aiempi Polymarketin kaupankäynti-API:n opas erottaa markkinadatan, toimeksiannot ja tilitiedot. Sopimusten löytäminen kuuluu rakenteen ensimmäiseen osaan. Ennen yksityisiä pyyntöjä integraation tulee pystyä näyttämään lukijalle, millä tuloksella se aikoo käydä kauppaa ja miksi tunniste vastaa tutkimuspäätöstä.

Käytä nykyistä integraatiorajapintaa

API-asiakas tulee sitoa dokumentoituun versioon ja tunnettuihin tuettuihin toimintoihin. Älä oleta vanhan pakettinimen, lompakkoesimerkin tai pyyntörakenteen olevan ajantasainen siksi, että se esiintyy oppaassa. Varmenna viralliset ohjeet ja asennettu kirjasto yhdessä.

Polymarketin nykyinen kaupankäynnin yleiskuvaus kuvaa selvitystä, johon osallistuvat pUSD ja tulostokenit. Integraation tulee siksi välttää vanhan vakuusoletuksen kovakoodaamista kaikkiin tilitoimintoihin. Rahoitukseen, käyttövaltuuksiin, kaupankäyntiin ja lunastukseen voi liittyä eri tietueita, jotka tarvitsevat omat ajantasaiset tarkastuksensa.

Kirjaa ohjeiden tarkastuspäivä ja sovelluksen käyttämä asiakasversio. Kun jompikumpi muuttuu, toista allekirjoituksista, määrien koodauksesta ja tilojen tulkinnasta riippuvat hyväksymistapaukset. Onnistunut markkinadatapyyntö ei osoita todennetun kaupankäyntipolun yhteensopivuutta saman version kanssa.

Yksilöi allekirjoittaja ja tililompakko

Pyynnön allekirjoittava osoite ja varoja tai positioita säilyttävä tililompakko eivät välttämättä ole keskenään vaihdettavia kaikissa lompakkojärjestelyissä. Integraation on selvitettävä niiden suhde nykyisen tiliasetelman perusteella. Sen päätteleminen tutusta osoitemuodosta voi johtaa valtuutusvirheisiin tai tilien sekoittumiseen.

Näytä odotettu tiliympäristö ennen kaupankäynnin sallimista. Hyödyllinen tarkastus kattaa kauppapaikan, lompakon identiteetin, tuetut käyttöoikeudet ja sen, vastaavatko nykyiset yksityiset lukupyynnöt tarkoitettua tiliä. Näin käyttäjä voi havaita teknisesti kelvollisen mutta väärään tiliin yhdistetyn määrityksen.

Virallinen lompakko- ja todentamisopas on oikea lähtökohta nykyisille lompakkokohtaisille asetuksille. Pidä salainen aineisto poissa tavallisista lokeista ja käyttäjälle näkyvistä tietueista. Elinkaaripäiväkirja tarvitsee tunnisteita ja näyttöä valtuutuksesta, ei yksityisavainten tai uudelleen käytettävien todentamistietojen kopioita.

Erota pyynnön todentaminen toimeksiannon valtuuttamisesta

Todentaminen selvittää, mikä tili tai todentamistieto tekee yksityisen pyynnön. Toimeksiannon valtuuttaminen vahvistaa itse allekirjoitetun kaupankäyntiohjeen. Ero on tärkeä, sillä kelvollinen pyynnön kuori ei oikeuta muuttamaan toimeksiannon sisäisiä taloudellisia ehtoja.

Polymarketin API-ohjeet kuvaavat lompakkoon perustuvien todentamistietojen määritystä ja todennettuja CLOB-pyyntöjä sekä erillistä toimeksiannon valtuuttavaa lompakkoallekirjoitusta. Integraation tulee noudattaa nykyisiä allekirjoitusvaatimuksia sen sijaan, että kaikkia allekirjoituksia käsiteltäisiin yhtenä yleisenä tunnisteena.

Säilytä sovellustasolla hyväksytty hinta, määrä, puoli ja voimassaoloaika ennen allekirjoitusta. Jos jokin näistä ehdoista muuttuu, ohjelman tulee käsitellä tulosta muuttuneena ohjeena, joka vaatii soveltuvat valtuutustarkastukset. Tiedonsiirtoa uudelleen yrittävä apuohjelma ei saa hiljaisesti väljentää hintarajaa tai kasvattaa määrää onnistuneen vastauksen saamiseksi.

Lue markkinarajoitteet ennen toimeksiannon rakentamista

Kelvollisen toimeksiannon on sovittava markkinan nykyisiin rajoitteisiin, kuten hintaportaisiin ja määrävaatimuksiin. Nämä ominaisuudet tulee lukea ja varmentaa eikä kopioida pysyviksi arvoiksi asiaan liittymättömästä esimerkistä. Rajoitteen muutos voi tehdä muuten järkevästä ohjeesta kelvottoman.

Käytä desimaalilaskentaa ja nimenomaisia yksiköitä muuntaessasi ihmisen päätöksen pyynnön määriksi. Osuuskohtainen hinta, osuuksien määrä ja vakuuksien kokonaiskustannus ovat eri suureita. Yhtä niistä sisältävää kenttää ei koskaan saa hyväksyä toista odottavaan kenttään vain siksi, että molemmat esitetään lukuina tai merkkijonoina.

Virallinen toimeksiantojen jättämisopas dokumentoi nykyisen rakentamispolun. Yleisessä työnkulussa keskeinen hyväksymistarkastus on se, että koodattu toimeksianto voidaan purkaa takaisin täsmälleen käyttäjän hyväksymiksi taloudellisiksi ehdoiksi sen jälkeen, kun tarvittava pyöristys on tehty näkyväksi ja tarkastettu.

Tarkasta tarjouskirja aiotulle määrälle

Hintaraja määrittää, mitä tili on valmis maksamaan tai saamaan. Se ei lupaa halutun määrän toteutumista. Tarkasta ennen välittömän toimeksiannon rakentamista rajan sisällä saatavilla oleva syvyys ja säilytä päätöksen käyttämän havainnon aika.

Oletetaan, että keksityssä tarjouskirjassa tarjotaan kymmentä osuutta 0,41 dollarilla ja kahtakymmentä 0,44 dollarilla. Kolmenkymmenen ostaminen maksaisi 4,10 dollaria ja 8,80 dollaria eli 12,90 dollaria ennen maksuja, jos tarjoukset pysyvät saatavilla. Kolmenkymmenen osuuden rajahintaosto 0,44 dollarilla sallii enintään 13,20 dollarin ostohinnan ilman soveltuvia maksuja.

Odotetun tarjouskirjakustannuksen ja valtuutetun enimmäiskustannuksen ero on hyödyllinen. Ensimmäinen kuvaa havaittua tilaisuutta, toinen rajaa toimeksiantoa. Kumpikaan ei takaa lopullista toteumaa. Tarjoukset voivat muuttua tarkastuksen jälkeen, ja toimeksianto voi hylkääntyä tai toteutua osittain tyyppinsä ja nykyisten markkinaolosuhteiden mukaisesti.

Valitse loppumäärän käytäntö harkiten

Toimeksiantotyyppi määrää, mitä tapahtuu, jos koko pyydetty määrä ei voi toteutua heti. Tarjouskirjaan jäävä toimeksianto voi jättää toteutumattoman sitoumuksen kirjaan. Välittömän osittaisen toteuman ohje voi päättyä positioon ilman aktiivista loppumäärää. Nämä ovat eri tilitiloja.

Polymarketin nykyiset ohjeet erottavat FOK:n, joka vaatii välittömän täyden toteuman tai peruutuksen, FAK:sta, joka toteuttaa saatavilla olevan määrän ja peruuttaa loput. Osittainen FAK-toteuma ei siksi jätä toteutumatonta osuutta tarjouskirjaan. GTC:llä ja GTD:llä on omat säilymis- tai vanhenemiskäytäntönsä.

Aiempi Polymarketin rajahintatoimeksiantojen automatisoinnin opas selittää, miksi voimassaoloaikaa ja toteumia on tarkasteltava yhdessä. Kirjaa aiottu loppumäärän käytäntö toimeksiantoaikomuksen tietueeseen, jotta myöhempi täsmäytys voi verrata todellista toimintaa hyväksyttyyn ohjeeseen.

Varaa kapasiteetti ennen lähettämistä

Tilin tulee varata valtuutetun toimeksiannon tarvitsema kapasiteetti ennen sen lähettämistä. Näin kaksi samanaikaista päätöstä eivät kumpikin nojaa samoihin käytettävissä oleviin varoihin tai tapahtumarajaan. Varaus on sovelluksen hallintakeino, ja se tulee täsmäyttää kauppapaikan todellisiin tilikäytäntöihin.

Kolmenkymmenen osuuden 0,44 dollarin rajahinnalle kuvitteellinen paikallinen käytäntö voisi varata 13,20 dollaria ja 0,30 dollarin maksuvaran, yhteensä 13,50 dollaria. Vara on keksitty tätä esimerkkiä varten eikä sitä saa käsitellä nykyisen kauppapaikkamaksun tarjouksena. Todellisen maksukäsittelyn tulee käyttää soveltuvia nykyisiä tietoja.

Varaa kerran taloudellista aikomusta kohden, älä uudelleen jokaiselle tiedonsiirtoyritykselle. Jos vastaus jää tuntemattomaksi, varauksen säilyttäminen auttaa estämään tiliä käyttämästä kapasiteettia, jonka alkuperäinen pyyntö on jo saattanut sitoa. Vapauta tai muuta varausta vasta, kun toimeksianto- ja kauppanäyttö tukevat uutta tilaa.

Tallenna toimeksiantoaikomus pysyvästi

Toimeksiantoaikomuksen tietue yhdistää tutkimuspäätöksen, riskihyväksynnän ja lopullisen pyynnön. Sen tulee sisältää vakaa paikallinen tunniste, tiliympäristö, sopimus, puoli, määrä, raja, voimassaoloaika ja hyväksynnässä käytetyt dataversiot. Tallenna se pysyvästi ennen kuin toiminto voi poistua prosessista.

Tietue mahdollistaa palautumisen kaatumisen jälkeen. Ilman sitä ohjelma voi käynnistyessään havaita tuntemattoman aktiivisen toimeksiannon eikä osaa yhdistää sitä omaan aiempaan toimintaansa. Se tukee myös ihmisen tarkastusta, kun pyyntö lähetettiin mutta vastaus katosi.

Polymarketin API-botin opas keskittyy rajattuun toimintaan tällaisissa epävarmoissa lähetyksissä. Myös käsin käytettävä API-työkalu hyötyy samasta päiväkirjasta. Tarkoituksena on säilyttää toiminnon merkitys riippumatta siitä, päättyikö verkkoviestintä häiriöttömästi.

Käsittele lähetysvastausta näyttönä

Onnistunut lähetysvastaus antaa näyttöä siitä, että kauppapaikka hyväksyi pyynnön tietyssä tilassa. Se ei ole yleinen toteamus siitä, että jokainen pyydetty osuus olisi muuttunut lopulliseksi selvitetyksi positioksi. Lue palautetut tilat ja tunnisteet niiden dokumentoidun merkityksen mukaisesti.

Tallenna vastaus alkuperäisen aikomuksen ja pyyntöajan yhteyteen. Säilytä hylkäyssyyt sen sijaan, että korvaisit ne yleisellä epäonnistumismerkinnällä. Hintaportaasta johtuva hylkäys, riittämätön käyttövaltuus ja tiedonsiirron aikakatkaisu vaativat eri jatkotoimia. Vain viimeinen voi jättää toteutustuloksen paikallisesti tuntemattomaksi.

Kuittausta ei koskaan tule käyttää ainoana lopullisen positionäytön perusteena. Sovelluksen tulee tilanteen mukaan pystyä ilmoittamaan lähetetty, aktiivinen, osittain toteutunut, peruutettu, vahvistusta odottava tai selvittämätön. Selkeät välitilat ovat informatiivisempia kuin yksi vihreä onnistumisilmaisin.

Seuraa toimeksiantoja ja kauppoja erikseen

Toimeksianto on ohje, josta voi syntyä yksi tai useampi kauppa. Sen jäljellä oleva määrä ja siihen liittyvät kauppatietueet vastaavat toisiinsa liittyviin mutta eri kysymyksiin. Täysin täsmäytetyllä toimeksiannolla voi yhä olla seurattavia kauppojen selvitystietoja, kun taas osittain täsmäytetty tarjouskirjaan jäävä toimeksianto voi säilyttää aktiivista määrää.

Polymarketin toimeksiannon elinkaari erottaa täsmäytyksen lopullisesta vahvistuksesta. Elinkaaritoteutuksen tulee säilyttää tämä ero päivittäessään tilinäkymää. Sen ei tule yhdistää kaikkia kauppatiloja samaan valmistuneeseen tilaan.

Keksityssä osittaisessa toteutuksessa oletetaan, että kahdestatoista kolmestakymmenestä osuudesta syntyy kauppa. Tilipäiväkirjan tulee yksilöidä nämä kaksitoista ja niiden kauppojen tila sekä selvittää sitten, mitä jäljelle jääville kahdeksalletoista tapahtui toimeksiantotyypin mukaisesti. Pyydetyn ja täsmäytetyn määrän erotuksen laskeminen on hyödyllistä, mutta se ei yksin osoita, onko loppumäärä yhä aktiivinen.

Täsmäytä osittainen toteuma loppumäärään

Jatketaan kuvitteellista kolmenkymmenen osuuden toimeksiantoa, mutta oletetaan vain kahdentoista osuuden toteutuvan 0,44 dollarilla. Niiden ostohinta on 5,28 dollaria. Jos toimeksianto oli FAK ja sen lopullinen vastaus vahvistaa loppujen peruutuksen, tilillä on kaksitoista hankittua osuutta eikä jäljelle jäävistä kahdeksastatoista ole toimeksiantosidonnaisuutta.

Jos kyseessä oli tarjouskirjaan jäävä toimeksianto ja kahdeksantoista on yhä aktiivisena 0,44 dollarilla, niihin liittyy enintään 7,92 dollarin lisäsitoumus ostohintaan. Lisää todellisen tilikäytännön mukainen soveltuva maksukäsittely. Näissä kahdessa tapauksessa toteutunut määrä on sama mutta jäljellä oleva kapasiteetti eri.

Myöhempi peruutuspyyntö vaikuttaa vain yhä peruutettavissa olevaan osuuteen. Se ei kumoa toteutuneita osuuksia. Lopullisen tilitietueen tulee siksi yhdistää toteutuneet kaupat, loppumäärän lopputila ja mahdolliset maksut sen sijaan, että peruutusta käsiteltäisiin kuin koko alkuperäistä toimeksiantoa ei olisi koskaan ollut.

Käsittele peruutusta kilpailuna toteutuksen kanssa

Peruutuspäätöksen ja tuloksen vastaanottamisen välillä toimeksianto voi toteutua lisää. Ohjelman on täsmäytettävä sekä peruutusvastaus että mahdolliset siihen liittyvät toteumat. Paikallinen painikkeen painallus ei osoita, että loppumäärä poistettiin ennen seuraavaa täsmäytystä.

Oletetaan tilin uskoneen kahdeksantoista osuuden olevan jäljellä, mutta viisi lisää toteutui peruutusta käsiteltäessä. Lopullinen positio on seitsemäntoista osuutta, ja kolmetoista poistetaan, jos loppumäärän peruutus onnistuu. Päiväkirjan tulee selittää lisätoteuma sen sijaan, että se merkittäisiin mahdottomaksi jo pyydetyn peruutuksen vuoksi.

Vältä koko alkuperäisen määrän korvaamista heti peruutusyrityksen jälkeen. Selvitä ensin todellinen jäljellä oleva altistus. Korvaaminen on uusi taloudellinen päätös, jonka tulee käyttää nykyisiä hintoja, nykyistä tilitilaa ja alkuperäisen strategian rajoja, mukaan lukien peruutusprosessin aikana mahdollisesti umpeutunut määräaika.

Käsittele peruutusta kilpailuna toteutuksen kanssaLive remainderCanceled remainderConfirmed tradeUnresolved tradeTRADING FIELD NOTESEDUCATIONAL RESOURCE
Toteutuneet kaupat ja toteutumattomat loppumäärät tarvitsevat erilliset tilat; toimeksiantotyyppi määrää, pysyykö toteutumaton määrä sidottuna.

Palaudu tuntemattomaksi jääneestä lähetyksestä

Jos yhteys katkeaa lähettämisen jälkeen, alkuperäinen toimeksianto on voitu hyväksyä. Seuraava vaihe on tutkia tätä aikomusta saatavilla olevan toimeksianto-, kauppa- ja tilinäytön avulla. Uuden asiaan liittymättömän toimeksiannon luominen voi kaksinkertaistaa altistuksen, vaikka ensimmäinen yritys näytti paikallisesti epäonnistuneelta.

Säilytä alkuperäiset tunnisteet ja varaus tutkinnan ajan. Käytä rajattuja kyselyjä ja dokumentoitua palautumiskäytäntöä. Jos tilitilaa ei voida selvittää, keskeytä siihen liittyvät uudet lähetykset ja esitä epävarmuus vastuulliselle käyttäjälle. Aikakatkaisun tulee muuttua nimenomaiseksi selvittämättömäksi tilaksi eikä keksityksi hylkäykseksi.

Vertailu kaupankäyntiin Kalshin API:lla auttaa erottamaan tämän yleisen hajautettujen järjestelmien ongelman kauppapaikkakohtaisista rajapinnoista. Molemmat ympäristöt vaativat täsmäytystä, mutta tunnisteet, todentaminen, skeemat ja toimeksiantokäytännöt on käsiteltävä kummankin kauppapaikan nykyisten ohjeiden mukaisesti eikä kopioitava sovittimesta toiseen.

Rakenna tila uudelleen yhteyskatkon jälkeen

Suoratoistopäivitykset auttavat nopeassa havainnoinnissa, mutta yhteydettömäksi jäävä asiakas tarvitsee palautumissuunnitelman. Hanki nykyiset tilitiedot, täsmäytä avoimet toimeksiannot ja hae olennaiset kaupat dokumentoiduilla rajapinnoilla. Vertaa palautettua tilaa sitten paikalliseen päiväkirjaan ennen uuden altistuksen sallimista.

Älä oleta uudelleen toistettujen viestien olevan uusia taloudellisia tapahtumia. Ennen uudelleenyhdistämistä ja sen jälkeen havaitun kaupan tulee vaikuttaa positiotietueeseen kerran. Vakaat tunnisteet ja versioiden käsittely mahdollistavat tämän. Kahteen kertaan saapunut tiedonsiirtotapahtuma ei saa kaksinkertaistaa toteutunutta määrää tai maksuja.

Kirjaa epävarma aikaväli ja sen sulkemiseen käytetty näyttö. Jos integraatio ei voi osoittaa kattavuuden täydellisyyttä, säilytä rajoite. Tilinäyttö voi näyttää varmennetut omistukset selvittämättömän täsmäytysongelman rinnalla sen sijaan, että se esittäisi puutteellisista virroista kootun näennäisen tarkan kokonaismäärän.

Erota kaupan selvitys tapahtuman ratkaisusta

Kaupan selvitys siirtää ostoon tai myyntiin liittyviä omaisuuseriä. Tapahtuman ratkaisu määrittää ennustesopimuksen tuloksen sen sääntöjen mukaisesti. Nämä ovat eri vaiheita. Vahvistettu osto ei tarkoita tapahtuman ratkenneen, eikä näennäinen tapahtumatulos todista tilin saaneen lopullista maksuaan.

Pidä erilliset tietueet hankituista positioista, markkinan ratkaisusta ja tiliin soveltuvasta lunastus- tai maksuprosessista. Olennaiset tunnisteet ja näyttö voivat erota toisistaan. Erottelu auttaa erityisesti silloin, kun positio pysyy avoimena pitkään alkuperäisen toimeksiannon jälkeen.

Polymarketin automatisoinnin opas sijoittaa vaiheet käsin tehtäviin, valvottuihin ja delegoituihin työnkulkuihin. Päätä, mitä vaiheita sovellus saa suorittaa ja mitkä vaativat tarkastusta. Rajatun kaupan lähetyslupaa ei tule tulkita rajattomaksi valtuudeksi kaikkiin myöhempiin lompakkotoimintoihin.

Tee Polymarket-tilin täsmäytyksestä selitettävää

Polymarket-tilin täsmäytys vertaa sovelluksen tietueita määräävään tilinäyttöön. Tuloksen tulee selittää positiot, avoimet sitoumukset, toteutuneet määrät, maksut ja selvittämättömät kohdat. Saldoero on tutkittava oire eikä luku, joka piilotetaan selittämättömällä oikaisulla.

Osittaisen toteuman esimerkissä tarkastajan tulee voida jäljittää alkuperäinen kolmenkymmenen osuuden aikomus kahdentoista osuuden toteumaan ja loppumäärän lopputilaan. Jos myöhemmät kaupat muuttivat positiota, niiden tulee näkyä erillisinä tietueina omine alkuperineen. Lopullisen kokonaismäärän tulee olla laskettavissa uudelleen näistä osista.

Pidä täsmäytys riittävän riippumattomana lähetyspolun virheiden havaitsemiseksi. Jos se vain luottaa samoihin paikallisiin oletuksiin, jotka tuottivat toimeksiannon, se voi toistaa virheen sen löytämisen sijaan. Luettavat selitykset ovat arvokkaita, koska käyttäjä voi usein tunnistaa väärän sopimus- tai tilikytkennän nopeammin kuin yleinen ristiriitakoodi paljastaa sen.

Varmenna kaupankäynti Polymarketin API:lla täydellisten tapausten avulla

Hyväksynnän tulee kattaa täysi toteuma, osittainen toteuma aktiivisine loppumäärineen, välitön osittainen toteuma peruutettuine loppumäärineen, hylkäys, peruutuskilpa ja tuntemattomaksi jäänyt lähetys. Jokaisen tapauksen tulee päättyä selitettävään tilitilaan tai nimenomaiseen selvittämättömään ehtoon, joka estää sopimattoman jatkamisen.

Aiempi Polymarketin API-kaupankäyntibotin opas antaa laajemman näkökulman tarkastettavaan asiakkaaseen. Arvioi elinkaaritietueella toteutuksen toimintaa, mukaan lukien uudelleenkäynnistys ja palautuminen, sen sijaan että testaisit vain toimeksiantopäätepisteen onnistunutta vastausta.

Täydellinen integraatio tekee jokaisen tärkeän siirtymän näkyväksi: mitä aiottiin, mitä valtuutettiin, mitä lähetettiin, mitä toteutui ja mitä tilillä nyt on. Tietue tukee huolellista toimintaa ohjeiden kehittyessä ja tekee virheistä diagnosoitavia sekoittamatta verkkovastausta, täsmäytettyä kauppaa ja lopullista täsmäytettyä positiota.

Jatka oppimista

Tutustu kaikkiin aineistoihin