Mafunzo ya Boti ya Polymarket · Sura 12 kati ya 32
Jinsi ya kugundua ujazo hewa wa Polymarket (oda zinazoonekana zimejazwa kumbe hazijajazwa), kutekeleza majaribio-upya ya idempotent, kutofautisha status=matched na oda iliyopumzika kwenye daftari, na kuvumilia hitilafu za muda.
Sura hii inafunika nini
Ujazo hewa ni hitilafu mahususi ya Polymarket ambapo CLOB inakubali mechi lakini chain bado haijathibitisha uhamishaji wa ERC-1155. Oda ya kufuatia ndani ya ~sekunde 5 inakataliwa kwa hitilafu ya kupotosha ya "balance: 0". Tiba ni idempotence na kusubiri kukamilika kwa muamala. Sura hii ni mwongozo wa mbinu wa uzalishaji tuliolipia kwa pesa halisi.
- Ujazo hewa ni nini
- status=matched dhidi ya status=delayed dhidi ya status=posted
- Mfumo wa upimaji: pima status kabla ya kusherehekea
- FOK kama kinga ya ujazo hewa
- Majaribio-upya ya idempotent na client_order_id
- Tukio halisi la uzalishaji: jinsi tulivyorekebisha letu
- Msimbo: mfumo wa gundua-kisha-tenda baada ya oda
Ujazo hewa ni nini
Ujazo hewa ni wakati CLOB API inajibu oda yako na status: "matched" lakini uhamishaji wa ERC-1155 kwenye chain bado haujakamilika. Kilinganishi cha CLOB ni haraka kuliko uzalishaji wa block za Polygon (~sekunde 2 kwa kila block). Kwa takriban sekunde 2-5 baada ya mechi ya API, pochi yako kwenye chain haishikilii token ambazo kilinganishi kinasema unazimiliki.
Hitilafu ya boti inajitokeza wakati kitendo cha kufuatia - kwa kawaida oda ya uuzaji ya GTC ya kuweka chukua-faida - kinapoendeshwa ndani ya dirisha hilo. CLOB inakagua salio la chain, inaona sifuri, na inakataa kwa not enough balance / allowance: balance: 0, order amount: N. Ujumbe wa hitilafu unalaumu ruhusa ya matumizi (allowance); sababu ni ucheleweshaji wa kukamilika kwa muamala.
Mara ya kwanza hili linapotokea unadhani ni hitilafu ya ruhusa ya matumizi na unapoteza masaa. Tiba ni rahisi: subiri, hakiki, kisha weka oda.
status=matched dhidi ya status=delayed dhidi ya status=posted
Jibu la kuweka oda linajumuisha uga wa status wenye thamani tatu zinazojali.
matched: oda ililingana dhidi ya daftari mara moja. Hisa zitakamilika katika sekunde 2-5. Hii ndiyo FOK/FAK zinarudisha zinaposhinda.delayed: kilinganishi hakikuweza kukamilisha papo hapo na kikapanga mechi. Nadra; kwa kawaida inaonyesha msongamano. Ichukulie kamamatchedkwa madhumuni ya mfumo wa subiri + hakiki.posted(pia inaitwalive): oda inapumzika kwenye daftari bila kujazwa. Inarudishwa na oda za GTC ambazo hazikulingana mara moja. Hisa haziathiriki; hakuna kitendo cha kufuatia kinachohitajika bado.
Kanuni ya uamuzi: ikiwa status ni matched au delayed, usiweke kitendo chochote cha kufuatia kinachohitaji hisa mpya hadi uhakiki uhamishaji wa chain.
Mfumo wa upimaji: pima status kabla ya kusherehekea
Mfumo wa uhakiki: baada ya mechi iliyofanikiwa, pima salio la CTF hadi lionyeshe token mpya, kisha endelea.
def wait_for_settlement(token_id, expected_size, timeout=15):
"""Block until on-chain balance reaches expected_size or timeout."""
start = time.time()
while time.time() - start < timeout:
bal = ctf_contract.functions.balanceOf(PROXY, token_id).call()
if bal >= expected_size:
return True
time.sleep(0.5)
return False
Kukamilika kwa kawaida: sekunde 2-5 katika hali nzuri ya mtandao, hadi 15s wakati wa msongamano wa Polygon. Kusubiri kwa sekunde 5 kunafunika 95% ya visa; kwa uzalishaji weka timeout kwa 15s na arifa kwenye timeout.
Kwa boti za mzunguko wa juu ambazo haziwezi kuzuia, mbadala ni kujisajili kwa matukio: angalia tukio la CTF TransferSingle kwa anwani yako ya proxy na chochea vitendo vinavyofuata kwenye risiti. Hii inasukuma usubiri kwenye foleni badala ya kuzuia kitanzi cha mkakati.
FOK kama kinga ya ujazo hewa
Kuchagua FOK badala ya FAK ni kinga ya sehemu dhidi ya machafuko ya ujazo hewa. FOK huijaza oda nzima au inarudisha cancelled; FAK inaweza kurudisha filled_size ambayo ni ya sehemu. Wakati ujazo wa sehemu unafuatiwa na oda ya uuzaji ya GTC yenye ukubwa wa oda ya awali, uuzaji unashindwa kwenye ucheleweshaji wa kukamilika pamoja na kutolingana kwa ukubwa - hitilafu mbili zinajumuika.
Kwa FOK, ukubwa ni wa aina mbili: ukubwa kamili ulilingana au hakuna kitu kilichotokea. Mantiki ya kuweka oda inayofuata daima inajua cha kutarajia.
Hii haiondoi haja ya kusubiri - hata mechi kamili ya FOK iko chini ya dirisha la kukamilika la sekunde 2-5. Lakini inaondoa aina moja ya tofauti za uwekaji hesabu.
Majaribio-upya ya idempotent na client_order_id
Hitilafu za mtandao wakati wa kuweka oda huzua hali mbaya zaidi: wito wa HTTP wa boti ulikwisha muda, lakini oda inaweza kuwa ilipokelewa au isiwe ilipokelewa. Kujaribu upya bila uangalifu kunaweza kuweka oda mara mbili; kutojaribu upya kunaweza kuangusha nafasi.
Suluhisho ni uga wa client_order_id kwenye kuweka oda. Tengeneza UUID ya uhakika kwa kila oda iliyokusudiwa; ikiwa seva imeona ID hiyo kabla, inarudisha status ya oda iliyopo badala ya kutengeneza nakala.
import uuid
oid = str(uuid.uuid4()) # generate once, retry with same value
for attempt in range(3):
try:
resp = c.create_and_post_order(args, OrderType.FOK, client_order_id=oid)
return resp
except (TimeoutError, ConnectionError):
time.sleep(0.5 * (2 ** attempt))
raise RuntimeError("post failed after 3 attempts")
Mfumo: tengeneza ID kwanza, jaribu upya kwenye hitilafu ya usafirishaji, kamwe kwenye kukataliwa kwa kimantiki. Uondoaji wa nakala upande wa seva ni kwa kila API-key, unadumu ~dakika 5.
Tukio halisi la uzalishaji: jinsi tulivyorekebisha letu
Kutoka kwenye shajara yetu ya uzalishaji, Mei 2025. Dirisha la dakika 60 ambapo boti ya biashara iliweka oda 22 za ununuzi za FOK, zote zililingana, lakini oda 14 tu za uuzaji za GTC zilikubaliwa. Nafasi 8 hazikuwa na njia ya kutoka iliyowekwa.
Chanzo hasa: boti iliweka oda ya uuzaji ya GTC ndani ya 800ms ya mechi ya ununuzi, mapema kabla chain haijahakiki uhamishaji wa ERC-1155. CLOB ilikataa kwa ujumbe wa "balance: 0"; boti iliandika hitilafu kwenye kumbukumbu lakini haikujaribu upya. Nafasi 8 zilibaki kimya hadi usuluhishi bila ulinzi wa chukua-faida. Tatu zilifungwa nje ya pesa; moja ilifungwa 0.99 kwa bahati.
Suluhisho lilitolewa kama usubiri unaozuia wa sekunde 5 kati ya ujazo wowote wa ununuzi na uwekaji wowote wa GTC kwa token ile ile. Limehakikiwa kupitia biashara 30 za karatasi pamoja na biashara 30 za moja kwa moja; hakuna hitilafu za balance-zero tangu hapo.
Somo: njia ya hitilafu ya kimya ni ghali zaidi kuliko ile ya kelele. Baada ya hili tulifanya hitilafu zote za ujazo hewa zichochee arifa ya Telegram, ili hali ya mkengeuko ya baadaye ionekane ndani ya sekunde.
Msimbo: mfumo wa gundua-kisha-tenda baada ya oda
Mfumo wa uzalishaji wa nunua-kisha-weka.
def buy_then_post_tp(token_id, size, buy_price, tp_price):
# 1. Place FOK buy
buy_args = OrderArgs(token_id=token_id, price=buy_price, size=size, side="BUY")
buy_resp = c.create_and_post_order(buy_args, OrderType.FOK)
if buy_resp.status != "matched":
return {"ok": False, "stage": "buy", "reason": buy_resp.status}
# 2. Wait for on-chain settlement (5s sane default; bump for congestion)
if not wait_for_settlement(token_id, expected_size=size, timeout=15):
return {"ok": False, "stage": "settle", "reason": "timeout"}
# 3. Confirm minimum size for GTC
if size < 5:
# GTC won't accept; fall back to ride-to-resolve or FOK sell at TP later
return {"ok": True, "stage": "buy_only", "note": "size<5, no GTC posted"}
# 4. Post GTC sell
sell_args = OrderArgs(token_id=token_id, price=tp_price, size=size, side="SELL")
sell_resp = c.create_and_post_order(sell_args, OrderType.GTC)
return {"ok": sell_resp.status in ("posted","live"), "buy": buy_resp, "sell": sell_resp}
Mfumo unavumilia hitilafu za kawaida: ujazo hewa, kukatika kwa mtandao kwa muda, ukubwa wa GTC chini ya kiwango cha chini. Unarudisha taarifa za kutosha kwa safu ya mkakati kuamua cha kujaribu upya dhidi ya kuandika kumbukumbu dhidi ya kuarifu.


