$Sreact.fragment" 3:I[339756,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"LoadingBoundaryProvider"] 13:I[253348,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js","/_next/static/immutable/chunks/2cgfe17yzs4b0.js"],"default"] :HL["/_next/static/immutable/chunks/0ix6vujw7ee1a.css","style"] :HL["/_next/static/immutable/chunks/3me7fmtkc4wgw.css","style"] :HL["/_next/static/immutable/chunks/0xtm7vbl319or.css","style"] :HL["/_next/static/immutable/chunks/3f7sd4nq-tt3m.css","style"] :HL["/_next/static/immutable/media/fba5a26ea33df6a3-s.p.08ssgmy_tb90r.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/immutable/chunks/0-97cwhccsuli.css","style"] 11:X 0:{"P":null,"c":["","docs","api","authentication"],"q":"","i":false,"f":[[["",{"children":["docs",{"children":[["slug","api/authentication","c",["brand-kit"]],{"children":["__PAGE__",{},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4100]},"$undefined","$undefined",4120],[["$","$1","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0ix6vujw7ee1a.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","link","1",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/3me7fmtkc4wgw.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","link","2",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0xtm7vbl319or.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/28nhklyuaf-g_.js","async":true,"nonce":"$undefined"}],["$","script","script-1",{"src":"/_next/static/immutable/chunks/1yr3mpizubdvt.js","async":true,"nonce":"$undefined"}],["$","script","script-2",{"src":"/_next/static/immutable/chunks/1ht-qf-q4tks1.js","async":true,"nonce":"$undefined"}],["$","script","script-3",{"src":"/_next/static/immutable/chunks/3gou7gbjwpu4x.js","async":true,"nonce":"$undefined"}],["$","script","script-4",{"src":"/_next/static/immutable/chunks/1ljrubmtyjhqb.js","async":true,"nonce":"$undefined"}],["$","script","script-5",{"src":"/_next/static/immutable/chunks/0pohkvjkyx0ml.js","async":true,"nonce":"$undefined"}],["$","script","script-6",{"src":"/_next/static/immutable/chunks/0e_plrpk4tuu-.js","async":true,"nonce":"$undefined"}],["$","script","script-7",{"src":"/_next/static/immutable/chunks/3egobnolkwoyy.js","async":true,"nonce":"$undefined"}],["$","script","script-8",{"src":"/_next/static/immutable/chunks/104stqri_an_6.js","async":true,"nonce":"$undefined"}],["$","script","script-9",{"src":"/_next/static/immutable/chunks/264ys8ckb-e39.js","async":true,"nonce":"$undefined"}],["$","script","script-10",{"src":"/_next/static/immutable/chunks/3w61dvn9304yj.js","async":true,"nonce":"$undefined"}],["$","script","script-11",{"src":"/_next/static/immutable/chunks/3j5_5chqftfmo.js","async":true,"nonce":"$undefined"}],["$","script","script-12",{"src":"/_next/static/immutable/chunks/11i8qm_sgbq8n.js","async":true,"nonce":"$undefined"}],["$","script","script-13",{"src":"/_next/static/immutable/chunks/0thm4tqk_qgt_.js","async":true,"nonce":"$undefined"}],["$","script","script-14",{"src":"/_next/static/immutable/chunks/0-qougt1b7wim.js","async":true,"nonce":"$undefined"}],["$","script","script-15",{"src":"/_next/static/immutable/chunks/213orb6ur0xf3.js","async":true,"nonce":"$undefined"}],["$","script","script-16",{"src":"/_next/static/immutable/chunks/3074gp72li5ko.js","async":true,"nonce":"$undefined"}],["$","script","script-17",{"src":"/_next/static/immutable/chunks/03p--y4p0cs1h.js","async":true,"nonce":"$undefined"}],["$","script","script-18",{"src":"/_next/static/immutable/chunks/08v4mbtubzcep.js","async":true,"nonce":"$undefined"}],["$","script","script-19",{"src":"/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","async":true,"nonce":"$undefined"}],["$","script","script-20",{"src":"/_next/static/immutable/chunks/0whkp1tczizef.js","async":true,"nonce":"$undefined"}],["$","script","script-21",{"src":"/_next/static/immutable/chunks/28czqhyf77eaq.js","async":true,"nonce":"$undefined"}],["$","script","script-22",{"src":"/_next/static/immutable/chunks/0neaff_kbqqhr.js","async":true,"nonce":"$undefined"}],["$","script","script-23",{"src":"/_next/static/immutable/chunks/2szcaahnw0h2j.js","async":true,"nonce":"$undefined"}],["$","script","script-24",{"src":"/_next/static/immutable/chunks/2bgdwqwdgngll.js","async":true,"nonce":"$undefined"}],["$","script","script-25",{"src":"/_next/static/immutable/chunks/0lb7bv83rp9fc.js","async":true,"nonce":"$undefined"}],["$","script","script-26",{"src":"/_next/static/immutable/chunks/3tkxe7g_791uv.js","async":true,"nonce":"$undefined"}],["$","script","script-27",{"src":"/_next/static/immutable/chunks/3adhiv949a347.js","async":true,"nonce":"$undefined"}]],"$L2"]}],{"children":[["$","$L3",null,{"loading":[["$","div","l",{"className":"RouteSkeleton-module__R8xXKG__article ","aria-busy":"true","aria-label":"Loading page","children":[false,[["$","span",null,{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__backLink"}],["$","div",null,{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__title"}],["$","div",null,{"className":"RouteSkeleton-module__R8xXKG__metaRow","children":[["$","span",null,{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__metaChip"}],["$","span",null,{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__metaChip"}],"$L4"]}],["$L5","$L6","$L7","$L8","$L9","$La","$Lb","$Lc"]],false,false,false,false]}],["$Ld"],null],"children":"$Le"}],{"children":["$Lf",{"children":["$L10",{},null,false,null]},null,false,"$11"]},null,false,null]},null,false,null],"$L12",false]],"m":"$undefined","G":["$13",["$L14","$L15","$L16"]],"S":false,"h":null,"r":"$undefined","s":"$undefined","a":"$undefined","l":"$undefined","p":"$undefined","d":"$undefined"} 17:I[144368,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js","/_next/static/immutable/chunks/1ia1gxupn26v6.js"],"DocsSidebar"] 60:I[339756,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"default"] 61:I[837457,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"default"] 63:I[897367,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"OutletBoundary"] 64:"$Sreact.suspense" 66:I[897367,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"ViewportBoundary"] 68:I[897367,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"MetadataBoundary"] :HL["/_next/static/immutable/chunks/3-91cw8_yv1vk.css","style"] 4:["$","span",null,{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__metaChip"}] 5:["$","div","0",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] 6:["$","div","1",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] 7:["$","div","2",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] 8:["$","div","3",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraphShort"}] 9:["$","div","4",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] a:["$","div","5",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] b:["$","div","6",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraph"}] c:["$","div","7",{"className":"RouteSkeleton-module__R8xXKG__skel RouteSkeleton-module__R8xXKG__paragraphShort"}] d:["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/3-91cw8_yv1vk.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 18:T1676,Turbine Studio Overview Turbine Studio is an AI workspace for building, backtesting, and running prediction market strategies. It is designed for traders and AI agents that want a high level strategy surface instead of a low level exchange integration surface. The core loop is simple: 1. Build describe a strategy in plain English and let Studio turn it into a structured strategy draft for prediction market execution. 2. Backtest replay the strategy against supported historical market and edge data to screen out weak, overfit, or operationally fragile ideas. 3. Run deploy the strategy to an independent Locus runner that belongs to the user, with venue credentials and execution isolated from Turbine's app. Studio is not a promise of profit and it is not a black box fund. It is a strategy development environment. You bring the thesis, Studio helps express it clearly, test it against available history, and run it with explicit limits. What Studio is for Studio is useful when you have an event market idea that can be written as rules: market making around wide spreads, mean reversion after a fast price move, reacting to external data such as crypto prices or weather data, avoiding markets with poor liquidity, capping exposure across related contracts, pausing when fills, spread, or volatility stop matching the original thesis. The product is intentionally centered on structured strategy drafts rather than arbitrary generated code. AI can help draft and revise the strategy, while Studio keeps the final rules readable and reviewable. The public surface These docs describe the user facing surface area of Studio: Area What it covers Build How natural language strategy ideas become structured strategy drafts. Strategy Specs How Studio represents strategy rules for review, backtesting, and deployment. Strategy Reference Every strategy parameter by venue, with example strategies you can copy. Backtest How Studio evaluates a strategy before live execution. Data Sources Supported market and edge data used in strategy research. Run How a strategy moves from draft to an independent deployment. Locus Deployments How each user gets a dedicated server through Locus (YCF25). Risk & Limits The controls that make a strategy bounded, inspectable, and stoppable. AI Agent Guide A concise operating guide for AI systems using Studio on behalf of a human. These docs avoid internal architecture details. They explain what a user or AI agent can ask Studio to do, what decisions they need to make, and what assumptions they should verify before going live. Supported workflow Studio works best when you keep the loop tight: 1. Start with a specific market or market family. 2. State the signal in plain language. 3. Add hard risk limits before asking for performance. 4. Backtest the first draft. 5. Remove bad ideas quickly. 6. Tighten the strategy only when the backtest explains why. 7. Deploy with small limits. 8. Monitor behavior against the original thesis. For example: Studio can translate that request into a structured strategy draft, ask for missing details, run a backtest where supported data exists, and prepare it for deployment. Key concepts Strategy thesis The human readable reason the strategy should exist. A good thesis names the market, signal, expected behavior, and the condition under which the idea should be abandoned. Strategy spec The structured strategy format used to represent strategy rules, risk limits, market selectors, loop timing, and data references. Market data Historical market data from supported venues, including Kalshi and Polymarket where available. This is used to simulate entries, exits, fills, spreads, and behavior around market structure. Edge data External data that a strategy can reference, such as Coinbase historical price data or National Weather Service data. Edge data is useful when the strategy is not purely based on prediction market prices. Backtest result A simulation artifact that helps you reject bad ideas, compare drafts, and understand sensitivity to fills, fees, liquidity, and timing. It is not a guarantee of live performance. Bot One running instance of a strategy on one venue, in either live or paper mode. A bot begins with a deploy and ends with a stop, and two bots may run the same strategy at once. A strategy is the code you edit; a bot is the thing that trades. Runner The single private execution host you have per venue family — Kalshi events, Kalshi Perps, Polymarket US, Turbine, and Kalshi + Polymarket US arbitrage share one runner, while Polymarket has its own because it executes from a different region. A runner hosts that family's bots in isolation from one another, so a bot crashing, stopping, or being deployed leaves its siblings running — the exception is a deploy onto a runner Turbine cannot reach, or a first deploy onto an out of date one, which rebuilds the runner and restarts every bot on it once. Turbine partnered with Locus (YCF25) so every user can deploy to their own runner rather than depending on a shared custodial execution path. Bot cap How many bots your plan lets you run at once across all venues, paper bots included. It is distinct from a runner's capacity, the engineering limit on how many bots one runner can host. Going over your cap never stops a running bot; it stops you deploying another. What Studio does not expose Studio does not require users or AI agents to know Turbine's internal services, persistence model, deployment plumbing, or private implementation details. The stable interface is the strategy workflow: write a strategy, inspect the strategy spec, run a backtest, review risks, deploy to a user controlled runner, monitor and revise. That is the surface area AI agents should target.19:T10d9,Build Strategies Build is the part of Turbine Studio where an idea becomes an executable strategy. You describe the trading behavior you want, Studio asks for missing details, and the AI drafts a structured strategy that you can inspect before testing or running. The goal is not to hide the strategy behind generated code. The goal is to make the strategy explicit enough that a human, an AI agent, and the Bot running it can all reason about the same plan. What you can build Studio is designed for prediction market strategies such as: spread capture and market making, mean reversion after a price dislocation, momentum or drift around scheduled events, panic fades after fast moves, data driven rules using external signals, position management and exit rules around market close, strategy variants for Kalshi and Polymarket style event markets where supported. The first draft should be narrow. "Trade all weather markets profitably" is too broad. "Fade Chicago high temperature YES contracts when NWS data implies a lower probability and the spread is under 5 cents" gives Studio enough structure to produce a testable draft. The build loop 1. Describe the thesis Name the market, the signal, the expected edge, and the failure condition. 2. Choose the market scope You can ask for one market, a market family, or a selector such as a category or venue specific identifier. Narrow selectors make backtests and deployments easier to reason about. 3. Define entry logic Entry logic says when the strategy should open a position or post liquidity. It can reference market prices, spread, time, volume, and supported edge data. 4. Define exit logic Exit logic says when the strategy should close, reduce, cancel, or stop adding exposure. 5. Set risk limits Risk limits are first class. A strategy should define max position, price bounds, maximum spend, stop conditions, and timing restrictions before it is backtested. 6. Inspect the strategy Studio produces a structured strategy draft. Treat this as the contract between your intent and execution. 7. Backtest Backtesting turns the draft into evidence. Good backtests do not only report upside; they reveal whether the strategy depends on unrealistic fills, stale data, or a tiny sample. 8. Deploy Once you approve the behavior, Studio can deploy the strategy as a Bot on your private runner for that venue, which hosts every Bot you run there. See Locus deployments. Good strategy prompts Strong prompts include the market, signal, action, risk cap, and stop conditions: Weak prompts usually skip constraints: Studio may still ask follow up questions, but the better starting point is a scoped thesis with explicit limits. What Studio asks for When a prompt is underspecified, Studio may ask for: venue or market family, trade direction, signal threshold, maximum position, price floors or ceilings, minimum liquidity, allowed holding period, exit conditions, whether the strategy should post maker orders or take liquidity, whether the strategy may use edge data, whether it should backtest before deployment. AI agents should answer these questions directly instead of inventing hidden assumptions. If a human has not supplied a risk limit, the agent should ask for one or choose a conservative default and clearly label it. The output Build produces a strategy draft. A draft normally includes: strategy type, market selector, data references, loop cadence, entry rules, exit rules, risk constraints, deployment preferences, backtest settings. Every field a draft can use is listed in the Strategy Reference, venue by venue, with example strategies. Studio can revise the draft repeatedly. The cleanest workflow is to change one behavior at a time, rerun the backtest, and compare the new result against the previous draft. AI friendly rules If you are an AI agent using Studio: Preserve the user's thesis in plain language. Prefer explicit strategy changes over vague "improve performance" requests. Never remove risk limits to improve a backtest. Treat missing data as a reason to pause, not a reason to assume. Backtest before proposing live deployment. Explain trade offs in terms of fills, exposure, liquidity, and overfitting. Build is where the strategy becomes legible. A legible strategy is easier to test, easier to deploy, and easier to stop.1a:T52a4,Strategy Specs A strategy spec is the structured document Studio saves for every strategy. It is the reviewable output Studio uses to turn a natural language trading idea into something that can be backtested, reviewed, and deployed. Studio's AI writes it in YAML, you can read it on the strategy's Config tab, and you change it by asking the AI in chat. A strategy spec is intentionally narrower than a general programming language. It expresses the strategy surface: what market to trade, what data to read, when to enter, when to exit, how much risk to take, and when to stop. Note: This page explains what a strategy spec is and how to review one. For the full list of parameters, with every key's type, default, allowed values and venue support, see the Strategy Reference. Jump straight to your venue: Kalshi, Polymarket, Polymarket US, Kalshi Perps or Arbitrage. Why strategy specs exist AI is good at drafting strategy logic, but arbitrary generated code is hard to audit. Strategy specs give Studio a safer target. A spec is: readable enough for you to inspect, structured enough for Studio to validate on every save, constrained enough to backtest, portable enough to deploy, explicit enough to revise without losing the original thesis. The spec is the source of truth. Studio checks every save in three steps: it parses the YAML, validates every value, and compiles the spec into the program your Bot runs. If any step fails, the change isn't saved, and the AI gets the list of problems to fix. When you deploy, Studio compiles the saved spec again, so a Bot always runs a version that passed. The Bot runs the spec, not the chat conversation. Shape of a strategy Kalshi, Polymarket and Polymarket US strategies share one shape. Each part of the spec answers one question: Question Spec area Which venue is this for? platform: kalshi, polymarket or polymarket_us Which market or markets? market What kind of strategy is this? strategy: one of five built in types, or custom How often should it check? loop.interval, in seconds (10 or more) When should it act? params for a built in type, rules for custom What outside data does it read? edge and derived (custom strategies, on some venues) How much can it risk? risk, plus the deployment risk limits you confirm when you deploy When may it trade? trading_schedule or active_window (optional). See When a strategy may trade. version: 1, platform, strategy, market, risk (with max_position and price_ceiling) and loop.interval are required. A custom strategy also needs at least one rule that sells or cancels. A built in type needs its required params keys, for example spread_floor and order_count for spread_capture. See Built in Strategies. Studio rejects any top level key it doesn't know. strategy_name is the label Studio shows. strategy_name_origin records whether you, the AI or a template named the strategy. name is an old key that Studio still accepts but ignores, so use strategy_name for the label. None of these three changes how the Bot trades. Kalshi Perps and Arbitrage strategies use their own shapes. See Kalshi Perps and Arbitrage. Example This Kalshi strategy follows Kalshi's Bitcoin above/below series, KXBTCD. It buys YES when Coinbase BTC has risen more than 1.2% over 15 minutes and the market's spread is 6 cents or less. It exits if that move reverses or when the market is within 30 minutes of closing. The market and every value are illustrative, not recommendations. Each KXBTCD event holds several markets with different strike prices, and YES on the market the Bot picks pays only if BTC settles above that market's strike. These rules never compare BTC with the strike (derived metrics can). The example shows how the parts of a spec fit together. It isn't a tested way to trade BTC moves. What each part does: market.series_ticker: on every cycle, the Bot finds the event in the series that closes soonest. By default it trades that event's most liquid market. risk: max_position: 2 is the most the strategy should hold in one market. Each buy's quantity comes from the rule's size. On Kalshi custom strategies max_position pre fills the deploy dialog's Max open contracts, which is the live cap. price_floor and price_ceiling keep each buy's limit price between 8 and 92 cents, but they don't skip buys outside that range (see Risk fields). max_entries_per_market: 1 allows one entry order in each market, and each new market in the series starts a fresh count. loop.interval: after each cycle finishes, the Bot waits 60 seconds before it starts the next one. edge.btc: reads Coinbase BTC USD. change_15m is a fraction, so 0.012 means +1.2%. With refresh: 30s and a 60 second loop, the Bot fetches fresh data every cycle and can ride out one failed fetch before it starts skipping cycles. See Edge data references. rules: checked top to bottom on every cycle, and the first rule whose when block matches acts. On Kalshi, an entry held back by a trading schedule, or in an older series market the Bot keeps only to manage its position, lets later rules run (see Custom Rules). The exits come first and only fire while you hold a position. The entry only fires while you're flat, and its own yes_best_ask condition is what keeps it from buying above 60 cents. The first time you deploy, Studio pre fills the deploy dialog from this spec: 1 contract and $1 per order, and 2 open contracts per market. When you update a Bot that's already deployed, the dialog starts from that Bot's current limits instead. Every order has to pass both the spec's checks and those limits. See Strategy risk fields vs deployment risk limits. This example is based on the first prompt under Good strategy prompts. Two parts of that prompt don't translate directly: "While the market mid has moved less than 4 cents." Custom rules see only the current market snapshot and have no memory of earlier prices, so this can't be written as a rule. A good spec leaves out what it can't express and says so, instead of inventing a key. "Cap exposure at $300." The closest key is risk.max_notional, a cap on the dollars spent on entries in each market during one deployment run. It isn't a cap across markets, and selling doesn't free budget. With one 1 contract entry per market, this example spends less than $1 per market anyway. How a rule reads Each rule has a name, a when block and an action. when holds either all (every condition must hold) or any (at least one must hold). A condition compares a field with a number in value, or with another field in value_field, using , =, == or !=. Always quote the operator (op: " ="), because an unquoted , = or != breaks the YAML. time_to_expiry takes a duration string such as "30m". Every other field takes a plain number. If either side of a comparison is unavailable on a cycle, such as yes_best_ask on a book with no YES asks, the condition is false whatever the operator, != included. The actions are buy_yes, buy_no, sell_yes and sell_no (Kalshi and regular Polymarket only), sell_all, cancel_all and skip. skip places no order, but it still counts as the match for that cycle. A buy's size is a number of contracts (shares on Polymarket), defaults to 1, and can't be larger than risk.max_position. See Custom Rules for every field and action. Market selectors Strategies should identify their market scope as precisely as possible. Each venue has its own selectors, and using another venue's selector is a validation error. Venue Selector What the Bot trades Kalshi ticker One market. It never moves to another. Kalshi event_ticker The first open market Kalshi lists for that event, checked again every cycle. Best for single market events. Kalshi series_ticker The soonest closing event of a recurring series. selection: most_liquid (the default) trades one bracket; selection: all trades every bracket. Kalshi query A market from the first open event whose title contains the text, searched live every cycle. It can't be backtested. Polymarket slug, condition_id, or yes_token_id with no_token_id One market. Polymarket series_slug or recurring A rolling series. The Bot moves to the next market when one ends. Polymarket US slug One market. event_slug and query also work, but they pick a market once when the Bot starts. Prefer an exact selector when you already know the market. Search style selectors are for exploring: a Kalshi query match can change between cycles. On regular Polymarket, event_slug and query are rejected on their own, and a Bot that still has one next to a concrete selector stops at startup. Ask Studio to replace them with a concrete market before you backtest or deploy. Caps such as max_entries_per_market and max_notional apply to each market separately. On a Kalshi series each new market starts fresh, and with selection: all every bracket gets its own caps, so your exposure grows with the number of brackets. See Kalshi market selection. Strategy types Studio can draft five built in strategy types, plus custom: Strategy type What it does spread_capture Quotes a YES bid and a YES ask around the mid when the spread is wide enough. mean_reversion Buys YES when YES is cheap, or NO when YES is expensive, then exits near a target price. panic_fade Buys YES after a sharp drop from the recent 5 minute high, then exits on a small recovery. observation_momentum Buys in the direction of a recent price move, with a size that grows while the move continues. It has no exit of its own. pre_announcement_drift Enters once in a window before the market closes, and can exit just before close. custom Runs your own list of rules instead of a fixed template. A built in type runs fixed logic that you tune with a flat params map. It never runs rules or reads edge data. Kalshi and regular Polymarket accept a rules block on a built in type but ignore it, and Polymarket US rejects it. An edge block is ignored on Kalshi and Polymarket US, and regular Polymarket rejects edge on every strategy type. Warning: On Kalshi, some built in exits sell YES whatever you hold. The exits of mean_reversion and pre_announcement_drift don't close a NO position, and the mean_reversion exit adds to it. A panic_fade exit, or a pre_announcement_drift exit after a partial fill, can sell YES the Bot never bought, which opens a NO position. Read the Built in Strategies caveats for your venue before you deploy one. Use custom when the behavior needs explicit conditions. Some features work only with custom: edge data, derived metrics, max_notional, max_loss (Kalshi only), and active_window. See Custom Rules. Risk fields Every spec has a risk block, and it should be one of the first things you review. These are the keys: Field What it limits Where it works max_position The most the strategy should hold in one market, in contracts (shares on Polymarket). A whole number above 0. Required. On Kalshi custom strategies the live cap is the deploy dialog's Max open contracts, which starts from this value. All three venues price_floor, price_ceiling The price band for buys, in dollars from 0 to 1. price_ceiling is required. All three venues max_entries_per_market Entry orders in each market Kalshi (any strategy type); Polymarket (custom only) max_notional Dollars spent on entries in each market Kalshi and Polymarket, custom only max_portfolio_positions Blocks buys into a new market once this many markets are active: every market your Kalshi account holds a position in (manual trades and other Bots included), plus markets where this strategy has a resting order. Kalshi max_loss Losses across the whole deployment run. At the limit the Bot cancels its orders, sells its own inventory and stops. Manual trades or another Bot's orders in the same market also trigger this halt. Kalshi, custom only On Kalshi custom strategies the price band clamps a buy's limit price instead of skipping the buy: an ask above the ceiling becomes a resting bid at the ceiling. The floor doesn't block cheap buys either: an ask below price_floor is sent at the floor price and can still fill at the lower ask. To skip entries outside a price range, put the range in the entry rule, as the example does with yes_best_ask. For a lower bound, add a condition such as yes_best_ask = 0.08. Other protections are written as rule conditions, or come from the deployment: Spread limits: a spread condition on the entry, such as spread Warning: The deploy dialog also shows a Max daily loss field, but no strategy Bot enforces it today. Don't rely on it as a loss stop. On Kalshi custom strategies, use risk.max_loss. AI agents should not remove risk fields to make a backtest look better. If a backtest improves only after risk limits are loosened, that is a result to explain, not a result to hide. max_entries_per_market max_entries_per_market works on Kalshi for every strategy type, and on regular Polymarket for custom strategies. Polymarket US doesn't support it. On Kalshi it isn't recommended with panic_fade, pre_announcement_drift or spread_capture: those strategies carry on as if a skipped entry had been placed, so a later exit or sell quote can sell YES you never bought and open a NO position. See risk.max_entries_per_market on Kalshi. On Kalshi, an entry order uses one allowance once it has any fill, while it's still resting, or if its final state is unknown. An order that ends cancelled or rejected with no fill gives its allowance back. Closing the position doesn't restore the allowance; a new market does, such as the next market in a series. The count belongs to one deployment run: deploying or updating the Bot starts it again from zero, but a restart of the same run doesn't. On Polymarket the count comes from your account's trade history in that market, so earlier runs and manual trades count too. It isn't recommended with a rolling Polymarket series: once one market reaches the cap, later markets in the series stay blocked until you redeploy. See Kalshi and Polymarket for the details. When a strategy may trade Two optional blocks limit when a strategy acts. Use one or the other: Studio rejects a spec that has both. trading_schedule works on Kalshi, with any strategy type. It sets weekly trading_hours and blackouts in a named timezone, such as America/New_York. It blocks only new entries. Exits, cancel_all and max_loss keep running. While a schedule is present, a sell only sells what this deployment run bought, or adopted when you deployed. It can be backtested. active_window works in custom strategies on Kalshi and Polymarket. It is one period with a start, an end or both, written as timestamps with an offset, such as 2026 10 15T18:30:00 04:00. Before start the Bot does nothing. At end it cancels resting orders once and stops evaluating, exit rules included. On Polymarket that cancel covers all of your open orders in that market, including manual ones. It never sells your positions. It can't be backtested. See Trading schedule and Active window for the full format. Edge data references A custom strategy can read supported outside data next to the venue's order book. You declare each source as a named alias under edge, list the fields your rules may read, and read them in conditions as edge. . . Provider Selector Example What it provides Refresh default (minimum) coinbase symbol BTC USD Crypto prices, returns, moving averages and MACD 5s (1s, or 5s if you list a candle field such as change_15m) nws station, a 4 letter weather station code KMDW (Chicago Midway) Station observations, forecasts and active alerts 5m (60s) economic_calendar event FOMC, CPI or FOMC,CPI Time until the next and since the previous announcement 15m (5m) You can declare up to 8 aliases. An alias name is up to 32 lowercase letters, digits and underscores, starting with a letter. Edge data works in custom strategies on Kalshi and Polymarket US. Regular Polymarket rejects the edge block. derived metrics, such as a forecast minus the market's strike, work only in Kalshi custom strategies. A strategy should define exactly how edge data affects behavior. This fragment reads an NWS forecast and gates an entry on it. The station and thresholds are illustrative, not recommendations: A complete strategy also needs an exit rule and the other required blocks. forecast_high_f is the next daytime forecast high in °F, so in the evening it refers to tomorrow. If edge data is unavailable or stale, the safe behavior is to avoid opening new risk. The Bot fails closed: If an alias can't be refreshed, the Bot reuses its last good values for up to three refresh periods. After that it skips the whole cycle for that market, including exit rules and the max_loss check. On Kalshi it also cancels its resting orders there. If the first fetch after the Bot starts fails, there is nothing to reuse, so the cycle is skipped right away. A single unavailable value, such as a late Coinbase candle, doesn't skip the cycle. Conditions that compare it are false, whatever the operator. A few NWS fields fail open instead. For example, alert_active reads 0 if the alerts lookup fails, so don't use it as your only safety exit. Every declared alias is kept fresh even if no rule reads it, and a failing one still skips cycles. Declare only what your rules use. See Edge Data for every provider field, refresh minimums and backtest support. Good strategy spec habits Keep strategy names descriptive. strategy_name can be up to 80 characters. Review the risk block first, then the exits. Write prices in dollars from 0 to 1: 0.60, not 60. Studio rejects price_ceiling: 60. Write fractions as fractions. A Coinbase change_15m threshold of 0.012 means +1.2%. 1.2 saves without an error, but it means +120%. Write numbers as plain numbers, with no quotes or units: interval: 60, not interval: "60s", which Studio rejects. Edge refresh and time_to_expiry values are the exceptions, because they take units. Use whole numbers for max_position, max_entries_per_market, max_portfolio_positions and loop.interval. Studio drops decimals there without an error, so max_entries_per_market: 0.5 turns the cap off. Put exits above entries. Gate exits on holding a position (position_size 0) and entries on being flat (position_size == 0). Prefer simple thresholds before complex formulas. Check spelling inside blocks. Studio rejects unknown top level keys, but a misspelled key inside market, risk, loop, active_window, params or an edge alias is ignored without an error. Use one market family per strategy. Each Studio chat is tied to one venue; cross venue strategies use Arbitrage. Backtest every material change, and know what can't be backtested: Polymarket US strategies, a Kalshi market.query, active_window, some edge data (Coinbase bid, ask, spread and spread_bps, and NWS stations outside the supported list), and some Polymarket features. See Backtest and Edge Data. Keep live deployment aligned with the backtested spec. Set the deploy dialog's limits so the spec's order sizes fit. Here is what a spelling mistake looks like. These keys aren't in the spec format, so Studio ignores them, and the required values they were meant to set are missing: These typos hit required keys, so the save failed. A misspelled optional key, such as max_notinal: 5, saves without an error, and the Bot runs with no spend cap. What not to put in strategy specs Do not use strategy specs as a place to encode private implementation details. They should not need internal service names, database structure, cloud topology, or proprietary deployment plumbing. Also keep these out: Credentials. Never put API keys, secrets or private keys in a spec or in chat. Venue credentials go through Studio's credential flow when you deploy. See Credential boundary. Keys the format doesn't have. Fields such as risk.max_position_usd or loop.interval_seconds aren't settings, and Studio ignores them. If part of an idea can't be expressed, the spec should leave it out, and the AI should tell you. Notes as extra keys. A top level key like description: is rejected. Keep your thesis in the strategy name and the chat. The public contract is strategy behavior. You and your AI agent should be able to understand the strategy without reading Turbine's internals. Where to find every parameter Page What's there Strategy Reference The shape of a spec, feature support by venue, units, and how validation errors look. Kalshi Selectors, series and brackets, risk keys, loop, active_window and trading_schedule. Polymarket Selectors, rolling series, shares and ticks, and backtest limits. Polymarket US Slug selectors and the supported subset of risk keys and rules. Built in Strategies Every params key for the five built in types. Custom Rules Conditions, fields, operators, actions and the logic checks Studio runs. Advanced Kalshi Rules Composite maker orders, per fill profit targets and stops, and rule level schedules. Edge Data Coinbase, NWS and economic calendar fields, and strike distance metrics. Kalshi Perps Perp markets, sizing and leverage, take profit and stop loss, and rules. Arbitrage Venue legs, outcome mapping, net edge limits and fees. Before you deploy, read Risk & Limits. For how to ask Studio for a strategy, see Prompting.1b:T8e7,Prompting Studio Studio works best when prompts are specific, bounded, and testable. Treat the AI as a strategy drafting partner: give it the thesis, ask it to draft a strategy, and then use backtesting to decide whether the idea deserves more attention. Prompt format A strong prompt usually includes: 1. market or venue, 2. signal, 3. action, 4. entry threshold, 5. exit rule, 6. risk limit, 7. data source, 8. deployment intent. Template: Examples Ask for a Structured Draft When you want a strategy you can inspect, ask for a Studio ready draft: You can also ask Studio to revise a draft: Ask for a backtest Backtests are most useful when the prompt frames them as a filter: Useful follow ups: "Which assumption drives most of the result?" "Did this depend on one outlier market?" "How many trades were simulated?" "How sensitive is it to spread limits?" "What happens if we cut max position in half?" "Show the worst drawdown and explain it." Ask for deployment conservatively Live deployment should be explicit: Avoid prompts like: That gives the AI too much room to change behavior without a clear approval point. Prompting rules for AI agents If you are an AI agent operating Studio: Make the user's thesis visible in your response. Produce a clear strategy draft when the user asks to build. Use conservative defaults only when the user has not specified a value. Mark assumptions clearly. Backtest before deployment. Never claim that a strategy is safe, guaranteed, or risk free. Never increase exposure to improve a backtest without explicit approval. Prefer "this idea should be rejected" over overfitting a weak result. Common failure modes Too broad "Trade weather markets" is not enough. Ask which geography, timeframe, forecast data, and action. No risk cap A strategy without max exposure is incomplete. Add a cap before testing. No exit Every entry needs an exit. Exits can be signal reversal, time to close, take profit, stop loss, stale data, or manual review. Data mismatch Do not use edge data that would not have been known at the simulated time. Backtests should not rely on future information. Performance chasing If each revision only tries to improve a metric, stop and restate the thesis. A strategy should have a reason to exist outside the backtest.1c:T9af,Studio Challenges Studio Challenges are meant to teach you how to change a strategy by talking to Turbine in plain English. You should not need to memorize internal keys or edit YAML by hand to finish them. Read the strategy first Each challenge has three parts: the lesson goal, the current strategy, the quiz once the strategy matches the goal. Before you type anything, read the goal and compare it with the strategy on the right. Ask yourself: What is this strategy already doing? What one thing is the lesson asking me to change? Is the lesson asking for a new signal, a tighter safety limit, or a clearer exit? The easiest way to work through a challenge is to tell Turbine exactly what to keep and exactly what to change. Examples: Risk challenges Risk lessons usually ask you to keep the trading idea and make the strategy safer. That often means changing one of these: maximum open contracts, allowed YES price range, maximum loss, buy size on a custom entry rule. Useful prompts: If the lesson is about safety, the strategy should still look like the same strategy after the edit. The signal stays the same. The limits get tighter. Add edge challenges Edge lessons ask you to add outside data that improves the entry decision. In these challenges, that usually means Coinbase BTC data. The important pattern is: 1. tell Turbine which Coinbase signal you want, 2. tell Turbine how that signal should affect the entry, 3. keep the rest of the strategy idea intact. Useful prompts: You do not need to tell Turbine the raw field names unless you want to. Plain English is enough if the signal is specific: Coinbase BTC price above a short moving average, Coinbase BTC above VWAP, Coinbase BTC 4 hour change positive, Coinbase BTC moving too fast or staying calm. If you want more background on supported market and edge data, see Backtest Data Sources. Exit challenges Exit lessons ask you to keep the entry idea and add a clearer way to get out. That usually means: take profit, stop loss, exit on signal reversal, exit near market close. Useful prompts: Quiz tips The quiz is checking whether you understand what changed in the strategy. If you miss a quiz question: read the strategy again, compare it with the lesson goal, focus on the one thing that changed, use the examples above if you want a quick refresher. The right answer is usually the part of the strategy that the lesson was teaching: the safety limit, the Coinbase signal, the exit rule, the strategy type.1d:T60d9,Strategy Reference Every strategy you build in Turbine Studio is saved as a short YAML document, the strategy DSL. This reference lists every parameter in that document, venue by venue: its type, default, allowed values, and what it does once a Bot is running. Start here to pick your venue, learn the shape of a strategy document, and see which features each venue supports. Then follow the links to the section for your venue or feature. What a strategy document is When you describe a strategy in Studio, Studio's AI writes it as a YAML document. You can read it on the strategy's Config tab, and you change it by asking the AI in chat. The document is the contract between what you asked for and what the Bot does: the Bot runs the document, not the conversation. Studio checks every save in three steps: 1. Parse. The YAML must be well formed, and every top level key must be one Studio knows. 2. Validate. Values must be in range, each key must be supported on your venue and strategy type, and custom rules must pass logic checks. For example, Studio rejects an exit rule that would fire right after every entry. 3. Compile. The document is turned into the program your Bot runs. If any step fails, the change isn't saved. The AI gets the list of problems and revises the strategy. The one exception is an arbitrage strategy whose markets are still search placeholders: Studio saves it as a draft that can't deploy until the markets are resolved. See Arbitrage. When you deploy, Studio compiles the saved document again, so a Bot always runs a version that passed. Every complete example in this reference is checked by an automated test that runs the same three steps. Examples that start with Rejected are checked to fail with the message they show. Importing a saved strategy A saved strategy's history does not prove its source still passes Studio's current checks. Its detail page offers import only when the saved document passes current validation and compilation; otherwise it shows Studio import unavailable, while the original document and saved history remain readable. An import that fails these checks reports the validation errors and creates no draft. A successful import creates an undeployed draft from the original document and preserves its venue, including platform: kalshi_perps on older saved strategies whose stored venue label was Kalshi. Backtest availability is checked separately: an unsupported backtest does not by itself prevent import, and a saved backtest does not guarantee import or deployment eligibility. Review the draft and risk settings before deploying. Deployment size limit A valid saved strategy can still be too large to deploy. The runner accepts at most 2,000,000 bytes in the complete code upload request, including credentials and signatures. Studio reserves 64 KiB for that metadata, leaving a 1,934,464 byte budget for the JSON encoded compiled code; browser checks also include any environment settings supplied with it. This measures UTF 8 bytes after JSON escaping, not YAML length or Python character count. The completed signed request must still fit the full limit. An oversized deployment or update is refused with strategy_too_large. Saving a draft does not remove this limit. Ask Studio to simplify the generated code while preserving the trading rules, then save and retry; upgrading the runner does not raise the limit. Note: Examples use small, illustrative values and placeholder markets to show how a key behaves. They are not recommendations of markets, sizes or thresholds, and nothing here suggests a strategy will be profitable. Read Risk & Limits before you deploy. Choose your venue The platform: line decides which venue the Bot trades on, which document shape applies, and which keys are allowed. There are five strategy families. A Studio chat is tied to one venue. You can't move a strategy to another venue by editing platform:. Studio rejects the change as a platform mismatch and also clears the strategy saved in that chat, so the AI has to write it again for the chat's venue. To trade on another venue, start a new chat there. Arbitrage documents always use platform: arbitrage. The venue pair comes from the second leg, venues.b.platform, which is polymarket or polymarket_us. Anatomy of a strategy document Kalshi, Polymarket and Polymarket US strategies share one document shape. A few keys identify the strategy. market, risk and loop say what to trade, how much and how often. params or rules holds the logic, optionally fed by edge and derived data. Two optional blocks control timing. Two either/or choices shape every document: params or rules. Built in strategies read params. strategy: custom reads rules and ignores params. On Kalshi and Polymarket a built in strategy accepts a rules block but never runs it. Polymarket US rejects it. active_window or trading_schedule. You can use one or neither, never both. Unknown top level keys are rejected, for example description: unknown top level field. The old key name is still accepted but does nothing; use strategy_name. A complete example This Kalshi strategy follows the 15 minute Bitcoin series. It buys YES when YES is cheap early in a window, and exits on a profit target or shortly before the window closes. The values are illustrative only. What each block does: version, platform, strategy: schema version 1, the Kalshi venue, and a strategy built from your own rules. See Custom Rules. strategy_name, strategy_name_origin: the label Studio shows. They don't change how the Bot trades. market.series_ticker: on every cycle, trade the event in the series that closes soonest. By default the Bot trades that event's most liquid bracket. See Kalshi. risk: the band buy limit prices are clamped into, the position size, and one entry per market. On Kalshi custom rules the floor clamps the limit price but doesn't block a cheaper fill, so the entry rule also checks yes_best_ask = 0.05. Each new 15 minute market starts a fresh entry count. loop.interval: after each cycle finishes, the Bot waits 30 seconds before it starts the next one. rules: exits come first, so they run before any entry is considered. Only the first rule whose conditions all hold acts on each cycle. When you deploy this example, Studio pre fills the deploy dialog with 1 contract and $1 per order, 2 open contracts per market and a $2 daily loss, so the 1 contract entry fits. See Strategy risk fields vs deployment risk limits. Kalshi Perps and Arbitrage documents Kalshi Perps and Arbitrage use their own document shapes. The prediction market keys above, such as market, edge and trading_schedule, are rejected at their top level. Kalshi Perps Arbitrage platform kalshi_perps arbitrage strategy trend_rider, breakout_hunter, dip_reverter, custom complementary, directional, custom Markets markets: 1 to 5 perp tickers such as KXBTCPERP venues.a (Kalshi) and venues.b (Polymarket or Polymarket US), mapping.a_yes_equals, and bucket for a Polymarket US daily series Size and risk sizing (margin × leverage), risk (take profit and stop loss percent), execution, funding_awareness risk.max_position_usdc per lock, edge and slippage limits in basis points, optional fees Cadence loop.interval: optional, defaults to 60 seconds loop.interval: required Logic params for the three archetypes; indicators, rules, setups and setup_rules for custom params for directional; rules for custom Reference Kalshi Perps Arbitrage Feature support across prediction market venues Kalshi, Polymarket and Polymarket US share a document shape, but not every key works on every venue. When a venue doesn't support a key, Studio usually rejects the save with a message that names the venue; the exceptions are listed under the matrix. The venue pages have the details. Some combinations save without an error but do nothing, or fail when the Bot starts. Watch for these: A rules block on a built in strategy, on Kalshi or Polymarket. An edge block on a built in strategy, on Kalshi or Polymarket US. The data is never fetched. A params block on a custom strategy. Conventions used across the reference Prices Prices are dollars per contract (or per share on Polymarket) on a 0 to 1 scale, which is also the market's implied probability. 0.05 means 5 cents and 0.60 means 60 cents. Always write dollars, never cents: price_ceiling: 60 is rejected as out of range. Which quote a price field reads (bid, ask, midpoint or last trade) and which side it refers to differ by venue. Each venue page says exactly. Kalshi Perps prices are dollars per perp contract, where a contract is a fixed fraction of one coin. Sizes Venue Size unit Notes Kalshi Whole contracts Each contract pays $1 if its side wins. Polymarket Shares (outcome tokens) Each market has a minimum order size, usually 5 shares. Budget caps can produce fractional sizes. Polymarket US Whole contracts YES is "long" and NO is "short" on Polymarket US. Kalshi Perps Dollars in, contracts out Each entry is sizing.margin_usd × sizing.leverage of notional, rounded down to whole contracts (or to 0.01 on markets that allow fractional trading). Arbitrage Dollars per lock risk.max_position_usdc caps what one lock spends across both legs. Contract counts are worked out from it. Whole number keys reject decimals: max_position: 2.5, size: 1.5 or cooldown: 2.5 is rejected, and 3.0 is accepted. That covers risk, loop, a rule's size, whole number params on built in strategies, and arbitrage risk and fees. Window lengths in Kalshi Perps archetype params are strict in the same way. Money amounts such as risk.max_notional, risk.max_loss, sizing.margin_usd and risk.max_position_usdc are dollars. Durations and times Where Format Examples loop.interval and every key ending in _seconds A whole number of seconds, not quoted 30 Built in timing params such as cooldown, entry_hours_before, blackout_minutes_before A whole number in the unit the name gives (cooldown is seconds) 60, 6, 15 time_to_expiry conditions A quoted string: one whole number plus one unit, s, m, h or d "30s", "5m", "6h", "1d" entry_profit_min_time_to_expiry (Kalshi) A positive whole number plus s, m or h "10m" Edge data refresh A duration whose units can combine; no d unit "30s", "5m", "1h30m" Polymarket market.recurring.interval; Kalshi Perps params.timeframe and indicators[].timeframe One value from a fixed list, not a free duration Polymarket: 5m, 15m, 1h, 4h, 1d. Perps: 1m, 1h, 4h, 1d (no 5m) trading_schedule windows Local 24 hour HH:MM in the schedule's timezone "09:30", "24:00" (end only) active_window A full timestamp with a UTC offset "2026 10 15T18:30:00 04:00" loop.interval: "30s" and loop.interval: "30" are both rejected: the interval must be a bare number. The interval is a pause after each cycle finishes, so the real time between cycles is the cycle's own run time plus the interval. Percent, fraction or basis points Kind Where you'll see it Example Dollars on a 0 to 1 scale Prices, price bands and thresholds on prediction markets 0.60 means 60 cents Fraction Edge data such as Coinbase change_15m and the _distance_pct fields (fractions despite the name), and NWS humidity and precipitation probability 0.003 means +0.3%; 0.70 means 70% Percent Kalshi Perps take_profit_pct, stop_loss_pct, max_slippage_pct, limit_offset_pct, size_pct 2 means 2% Basis points Arbitrage min_net_edge_bps, max_leg_slippage_bps and fees; Coinbase spread_bps 25 means 0.25% Strategy names strategy_name is the name Studio shows for the strategy, up to 80 characters. Studio shortens longer names when it saves. strategy_name_origin records where the name came from: user: you typed it. Studio keeps it as written. generated: Studio's AI wrote it. Missing or unknown origins, and the older value legacy, are saved as generated. curated: it came from a Turbine template. Neither key changes how the Bot trades. To change strategy_name, ask in chat. The Rename button in the Studio sidebar changes only the strategy's title in your list, not strategy_name. How validation errors look Once the YAML itself reads cleanly, each problem is reported as path: message, where the path points at the key, and Studio lists all of them together, not just the first. This Polymarket US strategy uses two features the venue doesn't support and loops too fast: Studio reports: Some problems are reported on their own, and the other checks wait until you fix them: Problems reading the document. A YAML formatting or type error, such as a quoted number, is reported alone, with a line number instead of a key path, for example line 13: cannot unmarshal !!str 30 into int. Structural problems, such as an unknown top level key, a missing market selector or a rule with no action, are also reported before any range or venue checks run. Rule logic. Logic checks on custom rules run only once every rule's keys and fields are valid. Their errors name the rules involved and give a sample market state that triggers the problem. See Custom Rules. What validation doesn't catch Typos inside params and edge aliases. Unknown keys there are ignored without an error, so a misspelled exit_targt: 0.6 saves and the default is used. Most nested keys in Kalshi Perps and Arbitrage documents behave the same way. Check spelling carefully. (Unknown keys inside market, risk, loop and active_window are rejected; see below.) Everything after a line. Only the first YAML document is read. Keep the whole strategy in one document, indented with spaces, not tabs. These mistakes do produce errors: A quoted number in risk, loop, a rule or any built in params key, such as interval: "30" or cooldown: "60". An unquoted , = or != operator, which breaks the YAML or reads as an empty operator. Quote every operator (op: " =") so you never hit this one. An unknown key inside market, risk, loop or active_window, such as risk.max_notinal, which fails with risk.max_notinal: unknown risk field. A decimal in a whole number key, such as interval: 10.9 or max_entries_per_market: 0.5, which fails with must be a whole number. 10.0 is fine. .nan or .inf anywhere a number goes, which fails with must be finite (or the key's range error). A mistyped optional built in param: post_only: "false" or no instead of false, exit_target: abc, or a drift_direction outside auto, bullish and bearish. See Built in Strategies. Strategy risk fields vs deployment risk limits Two separate layers limit what a Bot can do, and an order has to pass both wherever the venue's Bot reads the deployment limits. The strategy's risk block is part of the YAML. The deployment risk limits are set in the Risk limits section of the deploy dialog and belong to that deployment. Where you set them. Strategy risk fields live in the YAML, so you change them by asking Studio's AI, and Studio checks them on every save. Deployment risk limits are set in the deploy dialog each time you deploy. What happens at a limit. A strategy field can skip an entry, clamp an order's size or price, or halt the run. On Kalshi, Polymarket US and Kalshi Perps, a deployment limit refuses an order that would break it rather than shrinking it. The exceptions are exits: Kalshi exits (custom rule, per fill and built in) and max_loss liquidations, and every Polymarket US exit, are split into several orders that each fit Max contracts per order. Arbitrage works the other way: it sizes each lock to fit Max contracts per order, Max dollars per order, and what is left of Max open contracts and Max daily notional traded. Backtests. Backtests simulate the strategy's risk fields, with gaps that each venue page lists. They don't read the deploy dialog: a Kalshi backtest applies max_position as the per market cap instead. Strategy risk fields Parameter Type Default Allowed values What it does price_floor number (dollars) 0 0 up to but not including 1; below price_ceiling Lowest price for buys. All three venues. price_ceiling number (dollars) required above 0, up to 1; above price_floor Highest price for buys. All three venues. max_position whole number required above 0 Largest position in each market. All three venues. max_entries_per_market whole number 0 (off) 0 or more Entries in each market. Kalshi, any strategy; Polymarket, custom only. max_notional number (dollars) 0 (off) 0 or more Dollars of entries in each market. Kalshi and Polymarket, custom only. max_portfolio_positions whole number 0 (off) 0 or more Markets with a position across your whole Kalshi account. Kalshi only. max_loss number (dollars) 0 (off) 0 or more Loss halt for the whole deployment run. Kalshi custom only. The price band works differently by strategy type and venue. Built in strategies mostly use it as an entry gate, checked against the market price, and spread_capture clamps its quotes into it. Custom rules clamp the buy limit price into it instead, so on Kalshi a buy when the ask is below price_floor can still fill at the cheaper ask, and a default GTC buy when the ask is above price_ceiling rests as a bid at the ceiling. A Kalshi custom buy with entry_execution: immediate_or_cancel cancels any unfilled remainder instead. Exits are never clamped, on any venue, so an exit when the bid is below price_floor still sells at the bid. On Kalshi, entry counts, max_notional spend and the max_loss ledger belong to one deployment run. They start over when you deploy or update the Bot, and restarting the same run doesn't reset them. On Polymarket, the entry count and spend are read from your account's trade history in that market, so earlier runs and manual trades there count too. Note: On Kalshi and Polymarket US, the live per market cap on held plus resting contracts is the lower of max_position and the deploy dialog's Max open contracts, which Studio pre fills from max_position. Setting Max open contracts higher doesn't let the Bot hold more than max_position. Kalshi backtests block buys past max_position the same way. Deployment risk limits For Kalshi, Polymarket and Polymarket US strategies, Studio pre fills the dialog from your strategy. Max contracts per order comes from the largest single order the strategy sends: the biggest buy size (an omitted size counts as 1) or composite orders leg, or for built in strategies min(max_position, 10) for mean_reversion, max_position for observation_momentum, min(max_position, 5) for pre_announcement_drift, fade_size for panic_fade and 1 for spread_capture. Max dollars per order is the same number in dollars. Max open contracts and Max daily loss come from max_position. Max daily notional traded is the largest of the order size, max_position, and 10 × the order size. For Kalshi Perps, Max dollars per order is pre filled from sizing.margin_usd × sizing.leverage, plus the execution.max_slippage_pct allowance, rounded up to whole dollars. On runner version 29 or later, deployment risk settings belong to each Bot, even when several Bots share a runner. Updating one Bot's limits doesn't change another Bot's settings. When the running Bot's settings can be verified, its redeploy dialog starts from those limits. If readback is missing or unverified, the Config tab shows the running settings as unknown. Review the suggested limits in the deploy dialog before confirming an update. Older shared settings captured during a runner upgrade are unconfirmed; explicitly review and update that Bot's limits to confirm them. Starting a Paper Run also opens a Paper Run risk limits dialog before the run starts or Studio requests missing credentials. Review the limits and choose Start paper run. The confirmed values travel with the paper deployment, including when it reuses saved credentials. They apply to simulated orders only where that venue's Bot reads them, as listed below; regular Polymarket shows no editable deployment limits. Paper fills are simulated, not orders submitted to the exchange or confirmed exchange fills. For a live Bot with journal data, Today’s Usage appears under Risk Limits in Config; the Paper tab shows usage from simulated fills for its Paper Run. The Bot terminal’s Charts tab also shows the same usage below the chart when the run’s limits and usage data are available, using simulated fills for Paper Runs and journaled fills for live runs. Daily windows begin at 00:00 UTC. Live usage comes from the selected Bot’s current run, so compare it with what the venue counts: Kalshi: daily notional shows this Bot’s busiest market, using only its journaled fills. The runtime limit counts all account fills in each market, including manual trades and other Bots, so the display can understate usage. Polymarket US: daily notional shows this Bot’s journaled fills, while the limit counts the whole account across markets. The displayed remaining amount is an upper bound. Arbitrage: daily notional counts this Bot’s journaled fills on both legs. Kalshi’s displayed daily loss is an estimate from today’s realized P&L plus open position P&L in the journal. The Bot’s own check values open positions at the best bid and includes adopted inventory, so it can differ. If fills cannot be replayed or an open position lacks a recent mark, loss usage is shown as uncounted, not zero; the Bot still checks its limit. A displayed remaining amount does not guarantee another order will pass the runtime checks. Turbine MCP can inspect deployment status and activity, but deployment controls are unavailable through MCP. Use Turbine Studio to deploy, update, stop or recover a Bot. See Turbine MCP. Not every venue's Bot reads every limit, and the deploy dialog shows only the ones it does: Venue What the Bot enforces Kalshi Max contracts per order on every order (exits, custom and built in, and max_loss liquidations are split to fit; larger entries are refused), Max open contracts in each market (never above max_position), Max dollars per order on buys, Max daily loss (buys pause until 00:00 UTC once the deployment's P&L since then, realized plus unrealized, reaches it; exits keep running), Max daily notional traded (checked on buys; it counts every fill in that market since 00:00 UTC, including sells and trades the Bot didn't make), and the API error limit, which pauses new orders for one error window while reduce only exits keep running Polymarket US Max contracts per order (exits are split to fit), Max open contracts (never above max_position), Max dollars per order and Max daily notional traded, which counts your account's trades in every market and is checked on every order except a sell that reduces your position. The API error limit pauses new orders for one error window; sells that reduce your position keep running. Polymarket None, and the deploy flow shows no Risk limits. Your strategy's risk block and your wallet balance are the only size controls. Kalshi Perps Max dollars per order on entries, and an API error limit that pauses new entries for one error window (reduce only closes keep running) Arbitrage Max contracts per order, Max dollars per order, Max open contracts on each leg and Max daily notional traded (this Bot's fills since 00:00 UTC on both legs, at their limit prices), which set the size of each lock rather than refusing it, and the API error limit, which pauses new locks for one error window Note: Max daily loss pauses entries for the rest of the UTC day. On Kalshi custom strategies, risk.max_loss is the loss halt for a whole run: once the run's losses reach it, the Bot cancels its orders, sells the inventory it bought, and opens nothing new for the rest of that run. Where to go next Each link opens the first page of a section. That page covers what the section's topics share and lists the rest of its pages under In this section. Section What's there Kalshi Kalshi market selectors, series and brackets, risk fields, loop, active_window and trading_schedule. Polymarket Polymarket selectors, rolling series, shares and ticks, supported features and Paper Runs. Polymarket US Slug selectors, the supported subset of risk fields and rules, and how Polymarket US orders work. Built in Strategies Every params key for spread_capture, mean_reversion, panic_fade, observation_momentum and pre_announcement_drift. Custom Rules Conditions, fields, operators, actions, evaluation order, required exits and logic checks. Advanced Kalshi Rules Composite maker orders, max_combined_price, per fill profit targets and stops, and rule level schedules. Edge Data Coinbase, NWS weather and economic calendar fields, refresh rates, and derived strike distance metrics. Kalshi Perps Perp markets, execution, sizing and leverage, take profit and stop loss, archetypes, indicators, rules and setups. Arbitrage Venue legs, outcome mapping, net edge and slippage limits, fees, buckets and custom rules. For how strategies are tested and run, see Backtest, Run, Monitoring and Prompting.1e:T4718,Kalshi Strategy Reference This section lists every setting a Kalshi strategy accepts, what each one does when your Bot runs, and where live trading and backtests behave differently. It covers platform: kalshi (event contracts). Kalshi Perps has its own format; see Kalshi Perps. Studio's AI writes the strategy for you as a short YAML document. You don't have to write YAML by hand, but reading it lets you check that the strategy does what you asked. Studio checks the document every time it is saved and again when you deploy, so a strategy with an invalid setting is refused before it can trade. The check can't catch everything: misspelled keys inside params and edge aliases are ignored, and it doesn't confirm that a ticker exists. See Unknown and misspelled keys. All values in the examples in this section are illustrative. They show how the settings work, not what to trade or how much. Nothing here is a recommendation or a claim about results. In this section The Kalshi reference is split into these pages: Kalshi Market Selection: How a Kalshi strategy picks markets with ticker, event_ticker, series_ticker or query, how selection works on a rolling series, and which selector wins when more than one is set. Kalshi Risk and Loop Settings: Every Kalshi risk key (max_position, price_floor and price_ceiling, max_loss, max_entries_per_market, max_notional, max_portfolio_positions), what each one counts and when it resets, and the loop interval. Kalshi Active Window and Trading Schedule: Limit when a Kalshi strategy may trade with a one time active_window or a recurring weekly trading_schedule: timezones, windows, daylight saving, what a schedule blocks, and rule level schedules. Kalshi Example Strategies: Seven complete strategies that pass Studio's checks: a one shot event trade, a rolling crypto series, an every bracket sweep, a spend capped scale in, weekday hours, an event window and a scheduled built in, each with the deploy limits it needs. Kalshi Strategies the Validator Rejects: Common Kalshi strategy mistakes Studio refuses at save time, with the exact error and how to fix each one. This page keeps what every Kalshi strategy shares: a minimal strategy, the full parameter table, the document root keys, how built in strategies and custom rules run on Kalshi, and units and execution, including the deployment risk limits and backtest support. A minimal Kalshi strategy Every Kalshi strategy has the same skeleton: a version, the platform, a strategy type, the market, risk limits, a loop interval, and either rules (custom strategies) or params (built in strategies). About every 30 seconds (30 seconds after each cycle finishes), the Bot reads this one market. If it holds YES and the best YES bid is at least $0.70, it sells. If it holds nothing and YES can be bought for $0.40 or less, it buys 1 contract. The ticker is illustrative; Studio does not check that a ticker exists when it saves. All Kalshi parameters This is the complete list. Anything not in this table is either rejected or ignored (see Unknown and misspelled keys). Prices are dollars per contract from 0 to 1, so 0.05 means 5¢. Parameter Type Default Allowed values What it does version integer required 1 Format version of the document. platform string required kalshi Picks the venue. Must match your Studio session. strategy string required custom, spread_capture, mean_reversion, panic_fade, observation_momentum, pre_announcement_drift Custom rules or one of five built in strategies. strategy_name string none any text (Studio keeps 80 characters) Display name. No effect on trading. strategy_name_origin string generated when a name is set user, generated, curated Where the name came from. No effect on trading. name any none anything Old key. Accepted and ignored. market.ticker string one selector required a Kalshi market ticker Trade exactly one market. market.event_ticker string one selector required a Kalshi event ticker Trade the first open market Kalshi lists for the event. market.series_ticker string one selector required a Kalshi series ticker Follow a recurring series and trade its current event. market.selection string most_liquid most_liquid, all With a series: one bracket or every bracket. market.query string one selector required free text Search open event titles at run time. Not backtestable. risk.max_position integer (contracts) required whole number 0 Largest position per market, held plus resting. Pre fills the deploy dialog. risk.price_floor number ($) 0 0 to under 1, below the ceiling Lower edge of the price band. risk.price_ceiling number ($) required above 0 up to 1, above the floor Upper edge of the price band. risk.max_loss number ($) 0 (off) ≥ 0; above 0 only with strategy: custom Halts the deployment and sells its inventory after this loss. risk.max_entries_per_market integer 0 (off) whole number ≥ 0 Most buy orders per market per deployment. risk.max_notional number ($) 0 (off) ≥ 0; above 0 only with strategy: custom Most dollars spent on entries per market per deployment. risk.max_portfolio_positions integer 0 (off) whole number ≥ 0 Blocks entries into a new market once your account is active in this many. loop.interval integer (seconds) required whole number ≥ 10 Pause between evaluation cycles. active_window.start timestamp none (active from deploy) RFC3339 with offset; custom only The Bot idles before this instant. active_window.end timestamp none (never ends) RFC3339 with offset, after start; custom only Entries stop at this instant; exits and max_loss keep running. trading_schedule.timezone string required in a schedule UTC or an IANA name such as America/New_York Timezone for the schedule's days and times. trading_schedule.trading_hours list of windows omitted (all week open) 1 or more windows The only times new entries are allowed. trading_schedule.blackouts list of windows omitted (none) 1 or more windows Times new entries are never allowed. Wins over hours. [trading_schedule.[].days](/docs/strategy reference/kalshi/schedules#windows days start and end) list of strings required unique mon tue wed thu fri sat sun Days the window starts on. [trading_schedule.[].start](/docs/strategy reference/kalshi/schedules#windows days start and end) string HH:MM required 00:00 to 23:59 Local start time (included). [trading_schedule.[].end](/docs/strategy reference/kalshi/schedules#windows days start and end) string HH:MM required 00:00 to 23:59, or 24:00 Local end time (excluded). Earlier than start means overnight. params (spread_capture) map see built ins spread_floor, order_count, post_only, refresh_on_fill (no effect) Settings for spread_capture. params (mean_reversion) map see built ins entry_low, entry_high, exit_target, cooldown Settings for mean_reversion. params (panic_fade) map see built ins panic_threshold, fade_size, recovery_exit, max_fades Settings for panic_fade. params (observation_momentum) map see built ins lookback_periods, momentum_threshold, position_scale Settings for observation_momentum. params (pre_announcement_drift) map see built ins entry_hours_before, blackout_minutes_before, drift_direction, exit_on_release Settings for pre_announcement_drift. rules list required for custom 1 or more rules Checked top to bottom each cycle; first match acts. rules[].name string required non empty text without double quotes Label shown in logs and decisions. rules[].when.all / rules[].when.any list of conditions exactly one required 1 or more conditions AND (all) or OR (any) of the conditions. rules[].when.[].field string required 17 built in fields (listed under Custom rules on Kalshi), edge. . , derived. The value the condition reads. See Custom rules. rules[].when.[].op string required = == != (quoted) The comparison. rules[].when.[].value number or duration one of value / value_field a number; time_to_expiry takes "30s", "15m", "6h", "1d" Fixed threshold. rules[].when.[].value_field string one of value / value_field another numeric field Compare against another live field. rules[].action string one of action / orders buy_yes, buy_no, sell_yes, sell_no, sell_all, cancel_all, skip What the rule does. rules[].size integer (contracts) 1 for buys whole number, at most max_position (omitted or 0 means 1) Contracts per buy. Kalshi sells ignore it. rules[].orders list one of action / orders one YES buy and/or one NO buy Resting limit buys priced from the book. Advanced rules. rules[].orders[].side string required yes, no Outcome the leg buys. rules[].orders[].action string required buy Only buying is supported. rules[].orders[].size integer (contracts) required whole number 0 Contracts for this leg. rules[].orders[].price.reference string required best_bid, best_ask Book price the leg is anchored to. rules[].orders[].price.offset number ($) 0 between 1 and 1 Added to the reference price. rules[].orders[].post_only boolean false true, false Rest only as a maker. rules[].max_combined_price number ($) none above 0 up to 1 Cap on a paired YES + NO quote. rules[].entry_execution string omitted (GTC) immediate_or_cancel Optional fresh signal check and IOC submission for custom buys; no minimum fill guarantee. rules[].entry_profit_offset number ($) none above 0, below 1 Per fill take profit on a sell rule. rules[].entry_stop_loss_offset number ($) none above 0, below 1 Per fill stop on a sell rule. rules[].entry_profit_targets list none rows of entry_price, target_price (up to four decimals) Per fill profit table on a sell rule. rules[].entry_profit_min_time_to_expiry duration none whole s, m or h, e.g. "30m" Limits the profit table to earlier fills. [rules[].trading_schedule](/docs/strategy reference/kalshi/schedules#rule level schedules) schedule none same shape as trading_schedule; buy rules only Hours when one entry rule may buy. edge. map none up to 8 aliases; lowercase names such as btc; custom only (ignored on built ins) External data rules can read. See Edge data. edge. .provider string required coinbase, nws, economic_calendar Data source. edge. .symbol / station / event string the provider's one selector e.g. BTC USD, KLGA, FOMC,CPI What the source reads. edge. .fields list required names from the provider's catalog Values rules may read. edge. .refresh duration 5s / 5m / 15m by provider e.g. "10s", "5m" How long fetched values are reused. derived. map none up to 8; custom only A computed number such as spot minus strike. derived. .kind string required signed_distance_from_strike The calculation. derived. .observed string required edge. . The value the strike is subtracted from. Document root version Always 1. Leaving it out fails with unsupported DSL version 0 (want 1). Write it as the plain number 1, not "1". platform Write kalshi. Case and surrounding spaces don't matter. platform has no default: if you leave it out the strategy is not treated as Kalshi and is refused. A Studio session belongs to one venue, so you can't move a strategy to another venue by editing this line; Studio rejects the save as a platform mismatch. strategy custom runs your own rules. The other five values run a built in strategy tuned with params. Some settings only work with custom: active_window, max_loss, max_notional, derived, and the advanced rule keys. trading_schedule, max_entries_per_market and max_portfolio_positions are accepted by every Kalshi strategy type. A custom strategy needs at least one rule and at least one exit rule (sell_yes, sell_no, sell_all or cancel_all). strategy_name and strategy_name_origin strategy_name is the label Studio shows for the strategy. strategy_name_origin records whether you typed the name (user), the AI generated it (generated) or it came from a curated template (curated). Other values, including the older legacy, are saved as generated. Neither changes how the Bot trades. Renaming a strategy doesn't change its behavior. Unknown and misspelled keys Studio is strict everywhere except inside params and edge aliases: An unknown top level key is rejected, for example description: unknown top level field. Unknown keys inside market, risk, loop, active_window, rules, conditions, orders, trading_schedule and derived are rejected. A typo such as max_notinal fails with risk.max_notinal: unknown risk field. Unknown keys inside params and each edge alias are silently ignored. A typo such as refesh: 30s saves without an error, and the setting falls back to its default. Whole number settings (version, max_position, max_entries_per_market, max_portfolio_positions, interval, rule and order size) must be whole: interval: 10.9 fails with loop.interval: must be a whole number, got 10.9, while 10.0 is fine. Numbers in quotes ("30") and numbers with units (30s) are refused too. Formatting rules Keep the whole strategy in one YAML document. Anything after a line is ignored. JSON also works, because JSON is valid YAML. Anchors and aliases (&name, name) work anywhere, for example to reuse a condition. Merge keys ( Note: Max daily loss pauses entries for the rest of the day. risk.max_loss is the loss halt for a whole deployment: it sells the deployment's inventory and never trades that deployment again. See Risk & Limits for the wider picture and Monitoring for watching a live Bot. Backtesting and Deep Research Kalshi strategies can be backtested (see Backtest and Data sources), with these exceptions and differences: Setting Backtest market.ticker, series_ticker Supported market.event_ticker Supported; replays past events of the same series, trading each one's most liquid bracket market.query Not supported active_window Not supported trading_schedule (top level and rule level) Supported max_position Supported; blocks buys past it, for custom strategies too price_floor, price_ceiling Supported; out of band buys are clamped or skipped depending on the replay max_entries_per_market, max_loss Supported max_notional Supported, except for strategies that rest quotes with orders max_portfolio_positions Supported; counts only the backtest's own positions entry_execution: immediate_or_cancel Supported by the custom execution engine replay; with L2 depth, may fill partially or not at all and cancels the remainder. A delayed fill can occur outside the original signal range. Composite orders Partial: replayed as simulated resting orders; see Advanced Kalshi rules Per fill exits (entry_profit_offset, entry_stop_loss_offset, entry_profit_targets) Ordinary backtests only; not with composite orders edge, derived Partial: only fields your rule conditions read are loaded; see Edge data Backtests don't read your real account, and fills are simulated. Treat a backtest as a way to find problems, not as a forecast. A completed derived data backtest may cover less than the requested period. When a bounded subminute history repair clips the window, the result preserves the original requested UTC bounds, reports coverage_status: partial and includes repair_window in window_clip_reason. Execution uses the admitted window, not the full request. Other clipping reasons can remain alongside it; older sealed jobs without request provenance keep their existing metadata. Compare requested and actual bounds before treating a result as full period coverage. Derived Kalshi series backtests can admit hours without replay entries when archived listing snapshots verify a quiet period or an interval with nothing listed. These hours contain no simulated quotes or fills. At the window edges, only listed quiet hours next to replay data qualify; listing evidence alone does not make an entirely empty backtest usable. Unverified hours or a detected volume rise within a stable set of interior listings keep the existing gap and clipping rules, and serving limits still apply. A 30 day request does not guarantee 30 days of coverage. Derived maker backtests also apply an estimated memory serving limit (server default: 6 GiB; deployment settings can change it). When adding older hours would exceed it, the run keeps the newest admitted suffix and reports window_clip_reason: serving_limit with meta.derived_maker_admission.limiting_dimension: memory. Admission metadata includes estimated_memory_bytes and max_memory_bytes; this is an estimate, not a measured memory guarantee. If even the newest hour cannot fit, the backtest fails with a serving limit error rather than automatically retrying the same sealed inputs. Compare requested and actual UTC bounds before interpreting the result. Derived taker series backtests retain valid intervals and unaffected markets when a contract has an order book replay gap. The affected contract resumes from a fresh source opening or an independently sealed hourly book. Pending signals are cancelled across that gap; filled positions, costs, and risk state remain intact. No quotes or fills are fabricated inside excluded intervals. The result preserves the requested UTC bounds, reports coverage_status: partial, and records each excluded interval with its market ticker and reason in skipped_derived_intervals. Actual start and end describe the outer bounds of retained data, not uninterrupted coverage. If no usable intervals remain, Studio shows Historical replay is unavailable, naming the market and UTC gap bounds. Request a history repair, then choose Retry after history repair to retry the same strategy. This failure is a history problem; Studio does not offer Fix with AI to change your rules. An otherwise eligible Run action remains available after a failed backtest. Kalshi backtests and Paper Runs include simulated trade fees and cent alignment rounding. For partial fills of one order, rounding overpayment accumulates across fills. Each fill's rounding rebate is capped at that fill's trade and rounding fees, so its modeled net fee cannot be negative. Any unapplied overpayment stays on the same order for a later fill that can cover the rebate; it is not credited immediately. These are simulated fees, not a promise of a live rebate or fill. Deep Research is Kalshi only and covers crypto and weather markets. It runs many backtest variants of your strategy, re checking every variant as a normal save would. Anything that blocks a backtest (such as query or active_window) also blocks research.1f:T1acc,Kalshi Market Selection The market block tells a Kalshi event contract strategy (platform: kalshi) which markets to trade. This page covers each selector, how it resolves live and in backtests, how selection picks brackets on a rolling series, and what happens when more than one selector is set. For every other key, see All Kalshi parameters. A Kalshi strategy needs at least one market selector. Pick exactly one of these four: Selector Resolves to Rolls to new markets Backtest ticker That one market No Yes event_ticker The first open market Kalshi lists for the event, re checked every cycle Within the event only Yes, against past events of the same series (most liquid bracket of each) series_ticker The series' current event: one bracket, or every bracket with selection: all, plus series markets you still hold Yes, automatically Yes query The first open event whose title contains your text, then its first open market Can change between cycles No An empty value counts as not set. Polymarket selectors (slug, condition_id, neg_risk and the rest) are rejected on Kalshi, even neg_risk: false. market.ticker Pins the strategy to exactly one market, for example a single game or a specific strike. The Bot never moves to another market. Once the market closes, every order attempt is refused because the market is no longer open, so the Bot stops trading on its own. Don't use a ticker for recurring markets such as 15 minute or hourly crypto: the strategy stops as soon as that one market closes. Use series_ticker instead. Backtest: supported. The backtest replays that market's own history, so it fails for a market that has no history yet (typical for a future one off event). market.event_ticker Each cycle, the Bot asks Kalshi for the event's open markets and trades the first one in Kalshi's list. It doesn't rank by liquidity or volume, and it trades only one market of the event. If Kalshi's list order changes, the traded market can change between cycles. If the event has no open markets, that cycle errors with No open markets for event .... Use it for events that have a single market. For a multi outcome event, pin the ticker of the outcome you want. Backtest: supported with a twist. The backtest always replays past events from the event's series, not the event you named, and in each one it trades the most liquid bracket (as a series_ticker backtest does). Live, the Bot trades the first open market Kalshi lists for your event. Read the result as a check against similar past events. market.series_ticker Follows a recurring series (for example KXBTC15M, KXBTC or KXHIGHNY) and always trades its current event. Every cycle the Bot: 1. Reads the series' open events, reusing the current market list until the window closes or 60 seconds have passed, whichever comes first. New brackets and changes to the listing's quotes or volume may take until that refresh to affect selection. 2. Takes the markets that close soonest. Together these are the current event's brackets. 3. Picks brackets to trade with selection. 4. Also evaluates every other market of the same series where your account still holds a position or this Bot has a resting order. In markets from an older event, exit rules run but new entries are blocked (the log says the market is retained for management only). Brackets of the current event stay open for entries. Rollover gaps. Kalshi lists the next market a few seconds after the previous one closes. When no current market is listed, the Bot checks every 5 seconds and waits up to 360 s for 5 minute series, 960 s for 15 minute series, 1800 s for hourly, daily and weekly series, and 180 s when the frequency is unknown. After that the cycle errors with No open markets in series ... and tries again next cycle. A long wait happens inside the cycle, so that cycle takes longer than loop.interval. Note: If Kalshi labels a series' events with a cadence but doesn't report the series' frequency, the Bot can't tell which events are current and trades nothing; each cycle ends with No open markets in series .... If you see that message on every cycle, not just around a rollover, this series can't be traded with series_ticker; stop the Bot and pin a ticker or event_ticker instead. Per market limits apply to each market of the series. max_entries_per_market: 1 on a 15 minute series means one entry per 15 minute market, which can be up to 96 a day, not one in total. On a series with several brackets per event it can be more, because the Bot can end up entering more than one bracket (see selection). Exit rules on those older markets sell only this Bot's attributed inventory, including positions explicitly adopted at deployment, whether or not a trading_schedule is present. Manual trades and other Bots' positions are excluded (see Selling). Backtest: supported. The series' events in the backtest window are replayed, and selection is honored. market.selection Only valid with series_ticker, and only when no other selector is set. Anything else fails with market.selection: is supported only with a Kalshi market.series_ticker selector. Value What the Bot trades most_liquid (default) One bracket of the current event: brackets with a real two sided quote first, then higher volume. If the top bracket shows no quote, the Bot checks up to 8 live order books and takes the first with both sides. The pick is re made every cycle using the current, possibly cached market list. A bracket you still hold keeps being evaluated, and entry rules can fire there too, so the Bot can hold more than one bracket if the most liquid one changes. all Every bracket of the current event, one after another within each cycle. Each bracket gets its own rule evaluation and its own per market limits. With all, per market limits are not divided across brackets. Six brackets with max_notional: 0.60 can spend up to 6 × $0.60 = $3.60. Only max_loss (whole deployment) and max_portfolio_positions (whole account) are shared. market.query Searches Kalshi at run time. Each cycle the Bot reads one page of open events, takes the first whose title contains your text (ignoring case), and trades that event's first open market. If nothing matches, the cycle errors with No markets matching query .... The match is fragile and can change from one cycle to the next. Before you deploy, ask Studio to resolve the query into a ticker, event_ticker or series_ticker. Backtest: not supported. A backtest refuses a query selector. Selector precedence Studio accepts more than one selector in a document, but live trading and backtests read them in a different order: Live: series_ticker wins whenever it is set. Without a series: ticker, then event_ticker, then query. Backtest: ticker, then event_ticker, then series_ticker. With two selectors, the backtest can test a different market from the one your Bot trades. Set exactly one.20:T2f4c,Kalshi Risk and Loop Settings This page covers the risk block and loop.interval of a Kalshi event contract strategy (platform: kalshi): what each limit counts, when it resets, which strategy types accept it, and how it behaves in backtests. For every other key, see All Kalshi parameters. Risk The risk block holds your strategy level limits. max_position and price_ceiling are required; every other key is optional and 0 means off. These limits sit on top of the deployment risk limits you confirm when you deploy. An order must pass both. Some limits count per market, some per deployment, and one across your whole account: Limit Scope Resets on redeploy Strategy types max_position Per market (per bracket) n/a All price_floor, price_ceiling Per order n/a All max_entries_per_market Per market, per deployment Yes All max_notional Per market, per deployment Yes Custom max_loss Whole deployment, all markets Yes Custom max_portfolio_positions Whole Kalshi account n/a All A deployment starts each time you deploy or update the Bot. A restart of the same deployment keeps its counters. risk.max_position Type: whole number of contracts, required, greater than 0. No upper bound. The largest position the strategy should hold in one market (one bracket with selection: all). Built in strategies size orders from it: spread_capture stops refreshing its quotes in a market once it holds this many contracts, mean_reversion buys min(max_position, 10), pre_announcement_drift buys min(max_position, 5), and observation_momentum sizes orders up to it. panic_fade sizes by fade_size. Custom strategies: a buy rule's size can't exceed it (entry size exceeds risk.max_position from an empty position), and neither can the buy sizes of one composite orders rule added together (composite buy orders together exceed risk.max_position from an empty position), because all of its legs rest at once. While the Bot runs, every buy, built in or custom, is refused if the contracts held plus resting in that market would pass the lower of max_position and the deployment's Max open contracts limit. Studio pre fills Max open contracts from max_position. Raising Max open contracts above max_position doesn't let the Bot hold more; setting it lower makes it hold less. The refusal names the limit that bound: open contracts would be 3.0, exceeding risk.max_position=2. Sells are never capped. Both counts include everything your account holds or has resting in that market, including positions from manual trades or other Bots. Backtest: supported. Backtests block any buy that would push held plus resting contracts above max_position, for custom strategies too. risk.price_floor Type: dollars per contract. Default: 0. Allowed: 0 up to (not including) 1, and below price_ceiling. Lower edge of the price band. What it does depends on the strategy type: Custom rules: buy_yes and buy_no place a limit order at the current ask, clamped into the band. If the ask is below the floor, the limit is raised to the floor. That order can still fill at the cheaper ask, so the floor doesn't stop cheap buys. If you want to skip cheap entries, add a condition such as yes_best_ask = 0.05 to the rule. Built in strategies use it as an entry gate or a quote limit. For example, mean_reversion only buys YES above the floor, and panic_fade exits a fade when the price drops below it. For buy_no the band applies to the NO price. Sells are never clamped. With max_notional, every buy rule must satisfy size × price_floor ≤ max_notional (an omitted size counts as 1). Backtest: supported, with one difference: depending on the replay path, an out of band buy is either clamped (as live) or skipped. risk.price_ceiling Type: dollars per contract, required. Allowed: above 0 up to 1, and above price_floor. Leaving it out fails with risk.price_ceiling: must be in (0, 1]. Upper edge of the price band. On custom rules, a buy whose ask is above the ceiling is not skipped: the Bot clamps the bid to the ceiling, then moves it to a valid market price. Any unfilled bid rests on the book until it fills or is canceled. A resting entry like this counts toward max_entries_per_market and max_notional until it is canceled unfilled. Buy and composite quote prices are moved onto the market’s valid price steps after clamping. Choose bounds that contain a valid price. If a whole cent market has price_floor: 0.451 and price_ceiling: 0.459, the current live and maker replay rounding can produce a 0.46 limit, above the ceiling. A band with no valid price is not reliably rejected. When the market’s price steps are unavailable, rounding uses whole cents. To avoid resting bids when the market is above your limit, add an explicit condition to the rule, such as yes_best_ask Backtest: supported, with the same clamp or skip difference as the floor. risk.max_loss Type: dollars. Default: 0 (off). Allowed: ≥ 0, and above 0 only on custom Kalshi strategies. A positive value on a built in strategy fails with risk.max_loss: requires durable deployment run attribution, currently supported only for Kalshi custom strategies; a negative value fails with must be = 0. A loss halt for the whole deployment, not a per trade stop loss. The Bot measures the deployment's P&L across every market it traded: money from sales and confirmed settlements, minus the cost of inventory sold or settled, minus fees, plus what it still holds valued at the current bid, minus what that cost. Only fills from this deployment's own orders count, plus any positions you explicitly adopt when you deploy. When Kalshi reports a market as settled or finalized with a YES or NO result, the live loss ledger closes this deployment's remaining inventory at $1 per winning contract and $0 per losing contract, retaining its entry costs and fees. That inventory no longer needs an executable bid, even after the Bot rolls to another market. Settlement losses can still trigger the deployment's loss halt. A merely closed or determined market is still treated as held inventory; an unavailable market lookup or a settled market without a YES/NO result blocks new entries instead of assuming a payout. When P&L reaches −max_loss: 1. The Bot records the halt so it survives restarts. 2. It cancels its resting orders and sells its inventory at the bid with immediate or cancel orders, retrying each cycle until the inventory is gone. 3. It never opens a new position in that deployment again. Deploy or update the Bot to start a new deployment. The halt also triggers if your account's position in a traded market stops matching what the deployment's own fills explain, or a resting order there isn't this Bot's (reason attribution_mismatch). Don't trade by hand, or run another Bot, in the same markets as a Bot with max_loss. It fails closed: if a held side has no bid, P&L can't be measured and that market's cycle errors instead of trading. If the Bot can't save its risk state, it blocks new entries instead of trading without a reliable loss check (reason risk_state_unavailable). max_loss is checked every cycle the Bot evaluates a market. It is not checked before active_window.start. After active_window.end it keeps running in every market the Bot still holds or has resting orders in (see Active window), and an edge data or derived outage doesn't stop it either. Backtest: supported. The backtest applies the same calculation to simulated fills. risk.max_entries_per_market Type: whole number. Default: 0 (off). The most buy orders the Bot may place in each market during one deployment. Before every buy, the Bot checks this deployment's entry orders in that market on the exchange: An order uses a slot if it has any fill, is still resting, or its final state is unknown. An order that ended canceled with no fill gives its slot back. When the slots are used up, the buy is skipped (entry skipped: max entries per market reached). Sells are never limited. At 1 the cap is exact, which makes it the simplest way to say "enter this market once". Above 1 it is conservative, because several partly filled orders each use a slot. The count is per market (each new market of a series starts at 0) and per deployment (deploying or updating starts a fresh count; a restart does not). Note: When the cap skips a built in strategy's entry, the strategy doesn't advance: no cooldown starts, no fade is recorded, the momentum streak doesn't grow and drift isn't marked as entered. Built in exits only sell what the Bot holds. max_entries_per_market is still not recommended with spread_capture, whose YES sell quotes keep going out once the cap is reached, and a YES sell while you hold no YES opens a NO position. See risk.max_entries_per_market on Kalshi. Backtest: supported. Blocked buys show the reason max_entries_per_market. risk.max_notional Type: dollars. Default: 0 (off). Allowed: ≥ 0, and above 0 only on custom strategies (risk.max_notional: is only supported for custom strategies). A spend budget for entries in each market, not a limit on current exposure. The Bot adds up this deployment's entry orders in that market, each priced at its limit price: filled contracts plus contracts still open on orders that aren't finished. NO entries count at the NO price. A single buy is shrunk to fit: the Bot buys floor((max_notional − spent) ÷ limit price) contracts. If less than 1 contract fits, the buy is skipped (max_notional budget exhausted). A composite orders batch is skipped entirely if it doesn't fit. It is never shrunk. Selling does not give budget back. Once spent, the budget stays spent until you redeploy. Because spend is counted at the limit price, a fill at a better price leaves some budget unused. Every buy rule must be able to fit at least once at the floor price: size × price_floor must not exceed max_notional, or the save fails with entry cannot satisfy risk.max_notional within the configured price bounds. With size: 5 and price_floor: 0.05, 0.24 fails and 0.25 passes. Note: Always set size on buy rules when you use max_notional. Live, an omitted size buys 1 contract, but series backtests can size an omitted size buy to the whole remaining budget, so the backtest may not match what your Bot does. Backtest: supported for ordinary (taker) backtests. Strategies that rest quotes with orders can't be backtested with max_notional set (risk.max_notional enforcement is not simulated for maker backtests yet). risk.max_portfolio_positions Type: whole number. Default: 0 (off). Before every buy, the Bot builds the set of markets where your Kalshi account holds a position (from any source, including manual trades and other Bots) plus markets where this Bot has a resting order. If the buy is in a market that isn't in the set yet and the set already has this many markets, the buy is blocked. Adding to a market already in the set is allowed, and sells are never blocked. Because it counts your whole account, positions you hold elsewhere use up slots. Besides max_loss, it is the only risk limit shared across brackets with selection: all. Backtest: supported, but the backtest only counts this strategy's simulated positions, not your real account. Loop interval loop.interval is the number of seconds the Bot waits after finishing one evaluation cycle before starting the next. It is required, must be a whole number of at least 10 (must be = 10 seconds (prevents API rate limiting)), and has no maximum or default. Studio's AI usually suggests 30. It is not a fixed clock. The Bot runs a full cycle (find markets, read books, check rules, place orders) and then sleeps. The real gap between cycles is cycle time plus interval, and it grows with many brackets, slow responses or a series rollover wait. active_window boundaries are checked at the start of a cycle, so they can be seen up to one interval plus the cycle time late. A trading_schedule has its own once a minute timer and doesn't depend on the interval. Backtest: decisions happen every loop.interval seconds or at the resolution of the historical data, whichever is longer. With sub minute Kalshi data, intervals of 60 s or less must be a multiple of 5.21:T1c8a,Kalshi Active Window and Trading Schedule A Kalshi event contract strategy (platform: kalshi) can limit when it trades in two ways. A one time active_window runs a custom strategy for one fixed period and then stops it. A weekly trading_schedule sets recurring hours for new entries on any strategy type, while exits keep running. The two can't be combined. For every other key, see All Kalshi parameters. Active window active_window gives a custom strategy one fixed period to run in. Use it for a single evening's game or to stand down before a scheduled release. Set start, end or both. active_window: {} fails with requires at least one of start or end. Both are RFC3339 timestamps with an offset ( 04:00) or Z. A space instead of T, a bare date or a missing offset is rejected. Daylight saving is up to you, because the value is an absolute instant. end must be after start. Past times are accepted, so a past end makes the Bot idle from the start. Custom strategies only, and not together with trading_schedule or rule level schedules. What the Bot does, checked at the start of each cycle: Before start: nothing. No market lookups, no rules, no exits, no max_loss check. Between start and end: normal trading. First cycle at or after end: it cancels this deployment's resting entry orders (its buys), in any market, once. If a cancel fails it retries next cycle, and that cycle's exits still run. Its resting exit orders, your manual orders and other Bots' orders are untouched. After end: no new entries. A buy rule whose conditions match is skipped with the reason active_window.end reached, and the rules below it still run. The Bot keeps evaluating every market where your account still holds a position or it has a resting order, so sells, cancel_all, stop losses, take profits, per fill exits and max_loss keep working until you stop the Bot. With series_ticker those are the series' markets; with ticker, that market; with event_ticker, the event's markets; with query, the market the query finds. With nothing left to manage, it idles. Note: active_window never sells on its own. After end a position is only closed by your exit rules or max_loss; without them, it is held to settlement unless you close it yourself. With only end, the Bot trades from deploy until that instant: Backtest: not supported. A backtest refuses any strategy with active_window, because it targets future wall clock times. Remove it for a historical test. Trading schedule trading_schedule sets recurring weekly hours when the strategy may open positions. It works with every Kalshi strategy type, built ins included, and can be backtested. It can't be combined with active_window. Only timezone, trading_hours and blackouts are allowed, and each window may only hold days, start and end. A schedule needs between 1 and 32 windows in total, and must leave at least one minute of the week open (trading hours and blackouts leave no time for entries). trading_schedule: null is rejected; remove the key to turn the schedule off. trading_schedule.timezone Required. Write UTC or an IANA name with a /, such as America/New_York, America/Chicago or Europe/London. Abbreviations (EST, CST, GMT), Etc/GMT names, wrong capitalization and surrounding spaces are rejected with timezone must be an IANA name such as America/Chicago, or UTC. A correctly formatted name that isn't in Studio's timezone data fails with unknown timezone. The timezone is never guessed from your browser or the server, so choose it on purpose. trading_hours and blackouts trading_hours: when present, new entries are allowed only inside these windows. Everything else is outside trading hours. When omitted, the whole week is open except blackouts. blackouts: new entries are never allowed inside these windows. Blackouts are applied last and always win over trading hours. Leave out a list you don't need. An empty list (trading_hours: []) is rejected with omit unused window lists instead of providing an empty list. Windows: days, start and end days: a list of unique lowercase days, mon through sun. MON, monday and days: mon (not a list) are rejected. start: zero padded 24 hour HH:MM, included. 9:00 and 09:30:00 are rejected. Quote it ("09:30"). end: excluded. 24:00 means "until midnight" and is only allowed as an end. start and end must differ. Overnight: if end is earlier than start, the window crosses midnight and belongs to the day it starts on. days: [fri], start: "22:00", end: "02:00" covers Friday 22:00 to Saturday 02:00. A Sunday overnight window runs into Monday. What a schedule blocks and what keeps running Blocked: every buy while the current local minute isn't open. On custom strategies, a blocked entry rule is skipped and later rules (such as exits) still run. Keeps running: sells, cancel_all, stop losses, take profits and max_loss. Resting entries: every minute while entries are blocked, and once at startup, the Bot cancels its own resting entry orders. It leaves exit orders and other Bots' orders alone. Cancellation happens at minute boundaries, so an entry can still fill right at a boundary. What you'll see: a blocked entry is logged with the reason outside_trading_hours or schedule_blackout. While the Bot is still canceling entry orders after a boundary or a restart, entries wait with schedule_cancellation_pending. If the schedule's timezone data can't be loaded, the Bot blocks every entry (schedule_unavailable) instead of guessing. With or without a schedule, each sell is reduce only and capped at what this deployment owns on the side it sells, including positions you explicitly adopt when you deploy. Inventory reserved by pending or unconfirmed exits is unavailable to another exit. A NO position counts as NO whichever way Kalshi reports its fills. If there is nothing to sell, the exit fails with no unreserved Bot owned inventory for this exit. Note: After you update or redeploy a Bot, its exit rules can't sell contracts the previous deployment bought unless you adopt them at deploy. Close those positions yourself or adopt them. Backtest: supported on Kalshi, for custom and built in strategies. Daylight saving The Bot converts every real minute into local time in your timezone and then checks the schedule, so daylight saving is handled for you: Spring forward: a local time that is skipped never happens. A Sunday 02:00–03:00 blackout in America/Chicago blocks nothing on 8 March 2026, because that hour doesn't exist that day. Fall back: a repeated local time applies both times. A Sunday 01:00–02:00 blackout in America/Chicago blocks two real hours on 1 November 2026. Rule level schedules Custom buy_yes and buy_no rules can carry their own trading_schedule with the same shape. A rule may enter only when both its own schedule and the top level schedule (if any) are open. When a rule's schedule is closed, the Bot skips it and moves to the next rule, so you can write one entry rule per time of day, each with its own threshold. Rule schedules aren't allowed on sell, cancel_all or orders rules, with active_window, or in a strategy that uses orders anywhere. When any rule has a schedule, the Bot's resting entry orders also expire at the next schedule change. Details are on Rule Level Trading Schedules, and a full example is Time varying EMA distance entry thresholds.22:T1621,Kalshi Example Strategies This page collects complete Kalshi event contract strategies (platform: kalshi), from a one shot game trade to a built in strategy with a weekly schedule. Every key they use is listed in All Kalshi parameters. Each example below passes Studio's checks as written. Tickers and numbers are illustrative: they show how the settings fit together, not what to trade. Check the deployment limits noted under each example before deploying. One shot event trade Enter one game market at most once, with a spend cap, a stop and a target. max_entries_per_market: 1 allows one buy order in this market per deployment. If that order only partly fills, the rest keeps resting and no second order is placed. The worst case entry is 4 × $0.45 = $1.80, inside the $2.00 budget. Exits are ordered first, so a held position is always checked for the stop and target before any entry. Deploy: Max contracts per order and Max open contracts must allow 4, and Max dollars per order at least $1.80. Studio pre fills 4, 4 and $4. Rolling 15 minute crypto series Follow the current 15 minute BTC market, enter at most once per market, and flatten shortly before each market closes. The Bot moves to each new 15 minute market on its own. selection is omitted, so it trades the most liquid bracket. The entry cap resets for every new market, so this can enter up to 96 times a day. max_loss: 5.00 covers the whole deployment across all those markets. If P&L reaches −$5.00, the Bot sells its inventory and stops entering until you redeploy. Don't trade this series by hand while the Bot runs: a position the deployment can't explain also halts it. A market that still holds a position after the next one opens keeps running its exits, but gets no new entries. Deploy: Max contracts per order at least 2. Every bracket with a portfolio cap Buy cheap YES brackets across the whole current NYC high temperature event, with per bracket caps, an account wide cap and a loss halt. Every bracket gets its own entry cap and its own $0.60 budget. With 6 brackets the combined budget is $3.60. Here the entry cap binds first: one entry of 2 contracts at $0.12 or less is at most $0.24 per bracket. max_portfolio_positions: 4 counts every market with a position in your Kalshi account, plus markets where this Bot has resting orders. Positions you already hold elsewhere use up slots, so with 6 brackets at most 4 can be entered, and fewer if your account already holds other markets. max_loss: 3.00 is one ledger for the whole deployment, across all brackets. There's no stop rule: positions are held to settlement unless the take profit fires or max_loss halts the deployment. cancel_near_close only pulls resting orders. It sits below the take profit on purpose: the first matching rule ends the cycle, so a time only rule placed first would stop every rule under it from running in the last 30 minutes. Deploy: Max contracts per order at least 2. Spend capped scale in Add to a position in steps while the price stays low, with a dollar budget that caps total spending in the market. Each add buys 2 contracts at the ask. order_count == 0 waits until none of your orders is resting in this market. If all three adds are at $0.30, they cost $0.60, $0.60, and then the third is shrunk to 1 contract: floor(($1.50 − $1.20) ÷ $0.30) = 1. Selling doesn't give back budget or entry slots. Once $1.50 is spent or three entries are used, this deployment won't buy this market again, even after a stop or take profit. Deploy: Max contracts per order at least 2, and Max open contracts at least 6 (pre filled from max_position). Weekday hours with a blackout Trade the S&P 500 daily series only during US market hours on weekdays, with a Wednesday afternoon blackout. New entries happen only Mon–Fri 09:30–16:00 New York time, except Wednesday 13:45–14:30. This is the schedule drawn in the weekly grid under Trading schedule. The stop and take profit run at all hours, but because a schedule is present they only sell contracts this deployment bought. When the schedule closes, the Bot cancels its resting entry orders. If the most liquid bracket changes during the day, the Bot can enter more than one bracket; each has its own max_entries_per_market and Max open contracts. Deploy: Studio's pre filled limits (1 contract per order, 3 open contracts) fit this strategy. Event window that stands down Trade one game market only during a fixed evening, then cancel and stop. Before 18:30 ET the Bot does nothing. At 23:30 ET it cancels its resting orders once and stops running rules, including the stop and take profit. An open position is held to settlement. The worst case entry is 5 × $0.45 = $2.25, inside the $3.00 budget. This strategy can't be backtested, because of active_window. Deploy: Max contracts per order and Max open contracts at least 5, and Max dollars per order at least $2.25. Built in strategy with a schedule Run the panic_fade strategy on one market during weekday daytime hours. panic_fade buys fade_size YES after a drop of at least panic_threshold from the recent high, and sells when the price recovers by recovery_exit or falls below price_floor. See panic_fade for the full logic. The schedule blocks new fades outside Mon–Fri 08:00–23:00 ET. Exits keep running and only sell contracts this deployment bought. A fade opens only once its buy fills. A buy that hasn't filled after two loops is cancelled, and so is one still resting when the schedule closes at 23:00; neither counts toward max_fades. max_portfolio_positions works on built ins; max_loss, max_notional and active_window do not. Deploy: the defaults fit a fade_size of 1.23:T50e,Kalshi Strategies the Validator Rejects Studio checks a Kalshi event contract strategy (platform: kalshi) every time you save it, so a strategy with an invalid setting is refused before it can trade. Each example on this page shows a common mistake, the message you'll see, and how to fix it. Other rejected examples sit next to the setting they involve: an unknown top level key under Unknown and misspelled keys, selection with a pinned ticker under market.selection, and active_window combined with trading_schedule under Trading schedule. max_loss on a built in strategy risk.max_loss only works on custom Kalshi strategies. Remove it from a built in strategy, or use strategy: custom if you need a loss halt. A buy that can't fit max_notional Every buy rule must fit inside risk.max_notional at least once at the price floor: size × price_floor must not exceed max_notional. Here that is 5 × $0.05 = $0.25. Raise max_notional to 0.25 or more, or lower size or price_floor. Loop interval under 10 seconds loop.interval must be a whole number of at least 10 seconds. Set it to 10 or more. Timezone abbreviation in a schedule trading_schedule.timezone must be UTC or an IANA name such as America/New_York. Abbreviations such as EST are rejected, so write timezone: America/New_York instead.24:T31b5,Polymarket Strategy Parameters This page covers platform: polymarket: regular (international) Polymarket. If you trade on the US exchange, see Polymarket US instead. The two venues use different selectors and support different features. A Polymarket strategy has the same shape as a Kalshi one: version, platform, strategy, market, risk and loop, then params for a built in strategy or rules for your own. The runtime underneath is different, so the same keys can behave differently. This page gives you the overview: how Polymarket differs from Kalshi, a table of every key Polymarket accepts and the keys that are not available here. The details are split across the pages listed under In this section, and the linked rows in the parameter table take you straight to the right one. See the Strategy Reference overview for how the venue references fit together. Note: Examples on this page and its sub pages are illustrative shapes, not recommendations. Values are small on purpose. Choose your own markets, sizes and thresholds, and remember that automated strategies can lose money. See Risk & Limits. In this section Polymarket Market Selection: Every market selector (slug, condition_id, a YES/NO token pair, series_slug and recurring), which markets a Bot can trade, the discovery only event_slug and query, the fallback tick_size and min_order_size, and what carries over when a series rolls to its next market. Polymarket Units, Rounding and Risk: The units for prices, sizes, money and time, how buys are clamped and orders rounded onto the tick, the market's minimum order size, each risk key, and a note that Polymarket Bots don't enforce deployment risk limits. Polymarket Built in Strategies and Custom Rules: How each built in strategy enters, prices, sizes and exits on Polymarket, and what is specific to custom rules here: the 12 fields, the actions, how a custom buy is priced and sized, and what the validator checks. Polymarket Active Window, Paper Runs, Fees and Location: The one time active_window, Paper Runs, how fees are charged, and where live Polymarket trading is not available. Polymarket Example Strategies: Seven complete strategies that pass validation: custom rules on rolling crypto series and pinned markets (dollar P&L exits, NO book fields, a skip guard and a cancel_all for stale bids), plus the built in panic_fade on a token pinned market, mean_reversion and pre_announcement_drift. Polymarket at a glance Topic Kalshi Polymarket Markets per Bot One market, or several with a Kalshi series selector Exactly one binary market at a time. A series rolls to the next market. Choosing the market ticker, event_ticker, series_ticker, query slug, condition_id, a YES/NO token pair, series_slug or recurring Order books One YES/NO book Two separate books: one for the YES token, one for the NO token Units Whole contracts at 1 cent prices Shares, a per market price tick (0.1 down to 0.0001), a minimum order size (usually 5 shares), fractional sizes possible Custom buy price Best ask The side's midpoint, so buys can rest unfilled External data (edge), derived Supported Not available Time controls trading_schedule, active_window active_window only Loss and portfolio caps max_loss, max_portfolio_positions Not available Deployment risk limits Enforced by the Bot Not read, and not shown when you deploy. Your risk block is the limit. For Up/Down crypto markets, Up is YES and Down is NO everywhere on this page and its sub pages: in token IDs, actions and fields. All Polymarket parameters Every key Polymarket accepts. Rows that link go to the section of a sub page that covers the key in more detail. Parameter Type Default Allowed values What it does version integer required 1 DSL version. platform string required polymarket Selects regular Polymarket. Must match the venue of your Studio session. strategy string required custom, spread_capture, mean_reversion, panic_fade, observation_momentum, pre_announcement_drift Your own rules, or a built in strategy. strategy_name string none free text, stored up to 80 characters Display name. strategy_name_origin string generated user, generated, curated; anything else, including legacy, is treated as generated Where the name came from. Metadata only. name any none any Legacy key, accepted and ignored. Use strategy_name. market mapping required one concrete selector The market the Bot trades. See Market selection. market.slug string none a Polymarket market slug Pins one market by its URL slug. market.condition_id string none a 0x… condition ID Pins one market by its condition ID. market.yes_token_id string none a token ID The YES (Up) token. Needs no_token_id. market.no_token_id string none a token ID The NO (Down) token. Needs yes_token_id. market.series_slug string none a Polymarket series slug Follows a rolling series, one market at a time. market.recurring mapping none kind, asset, interval Shorthand for the crypto Up/Down series. market.recurring.kind string updown updown The only kind on regular Polymarket. market.recurring.asset string required in recurring btc, eth, sol, xrp, doge, hype, bnb Which asset's series to follow. market.recurring.interval string required in recurring 5m, 15m, 1h, 4h, 1d Length of each market in the series. market.recurring.event_slug_prefix string none any Accepted and ignored here. Used only by arbitrage. market.event_slug string none an event slug Discovery only. Cannot be deployed. market.query string none free text Discovery only. Cannot be deployed. market.neg_risk boolean false false true is rejected: multi outcome markets are not supported. market.tick_size string or number 0.01 0.1, 0.01, 0.001, 0.0001 Fallback price tick for token pinned markets. market.min_order_size string or number 5 a positive number Fallback minimum order size, in shares, for token pinned markets. risk mapping required max_position, price_floor, price_ceiling, max_entries_per_market, max_notional Position and price limits. See Risk keys on Polymarket. risk.max_position whole number (shares) required greater than 0 Most YES + NO shares held in the current market. risk.price_floor number ($ per share) 0 0 or more, below 1 and below the ceiling Lowest price the Bot buys at. Clamps every live buy. risk.price_ceiling number ($ per share) required above 0, up to 1, above the floor Highest price the Bot buys at. Clamps every live buy. risk.max_entries_per_market whole number off 0 or more; custom only Caps buy orders per market. risk.max_notional number ($) off 0 or more; custom only Dollar budget for buys in the current market. loop mapping required interval How often the Bot runs. loop.interval whole number (seconds) required 10 or more How often the Bot checks the market and runs its logic. active_window mapping always active start, end (at least one); custom only One time trading window. active_window.start timestamp none RFC 3339 with offset, e.g. 2026 10 04T09:00:00 04:00 The Bot does nothing before this time. active_window.end timestamp none RFC 3339, after start The Bot cancels its own resting buys and stops entering; exits keep running. params mapping none depends on the strategy Built in strategy settings. See Built in strategies on Polymarket. params.spread_floor number ($) required for spread_capture greater than 0 Minimum YES spread before quoting; also sets quote distance. params.order_count whole number required for spread_capture greater than 0 Price levels quoted on each side. params.post_only boolean false unquoted true or false only spread_capture quotes are maker only. params.refresh_on_fill boolean false true, false Accepted; no effect on Polymarket. params.entry_low number (YES price) required for mean_reversion below entry_high Buy YES at or below this price. params.entry_high number (YES price) required for mean_reversion above entry_low Buy NO when YES is at or above this price. params.exit_target number (YES price) 0.5 a number Sell everything when YES is within ±0.02 of this. params.cooldown whole number (seconds) 60 0 or more Minimum time between entry attempts. params.panic_threshold number ($) required for panic_fade greater than 0 Drop from the 5 minute high that triggers a buy. params.fade_size whole number (shares) required for panic_fade greater than 0 Shares bought per fade. params.recovery_exit number ($) 0.04 a number Rise above the entry price that triggers the exit. params.recovery_target number ($) none a number Legacy key; ignored by live and Paper Bots. Use recovery_exit. params.max_fades whole number 3 a whole number Most fades per Bot run. params.lookback_periods whole number (loops) required for observation_momentum 2 or more How many recent loop samples of the YES price to compare (newest minus oldest); it can fire once 2 samples exist. params.momentum_threshold number ($) required for observation_momentum greater than 0 Minimum move that triggers a buy. params.position_scale string linear linear, exponential How order size grows on repeated signals. params.entry_hours_before whole number (hours) required for pre_announcement_drift greater than 0 When the entry window opens before the end date. params.blackout_minutes_before whole number (minutes) required for pre_announcement_drift 0 or more Final minutes with no entries. params.drift_direction string auto bullish, bearish Which side to buy. Anything else means auto. params.exit_on_release boolean false unquoted true or false only Sell everything when the blackout starts. Never fires with blackout_minutes_before: 0. rules list required for custom 1 or more rules, at least one exit Your if/then rules. See Custom rules on Polymarket. rules[].name string required non empty text Label shown in logs and decisions. rules[].when mapping required exactly one of all, any The rule's conditions. rules[].when.all[].field (or any[]) string required one of the 12 Polymarket fields The live value to compare. rules[].when.all[].op string required , =, ==, != Comparison operator. Quote it in YAML. rules[].when.all[].value number or duration none an unquoted number; for time_to_expiry a whole number duration such as "90s", "5m", "6h", "1d" ("1.5h" is rejected; write "90m") Fixed value to compare against. rules[].when.all[].value_field string none another field Compare against another live field instead. rules[].action string required buy_yes, buy_no, sell_yes, sell_no, sell_all, cancel_all, skip What happens when the rule matches. See Actions. [rules[].size](/docs/strategy reference/polymarket/units and risk#order size and the market minimum) whole number (shares) buys: 1; sells: all held 0 or more; buys up to max_position Shares per order. Unknown keys inside market, risk, loop and active_window are rejected, so conditon_id, max_notinal or active_window.timezone fails with an unknown … field error, as do unknown top level keys and unknown rule keys. Unknown keys inside params are still ignored without an error, so check their spelling. Not available on Polymarket These keys are rejected when platform is polymarket: market.ticker, market.event_ticker, market.series_ticker are Kalshi selectors. Use slug, condition_id, a token pair, series_slug or recurring. market.selection is Kalshi's multi market mode. A Polymarket Bot trades one market at a time; use series_slug or recurring to follow a series. risk.max_loss is Kalshi custom only. The closest option is a sell_all rule on unrealized_pnl, which can match only while the Bot can value your position (see Fields). risk.max_portfolio_positions is Kalshi only. There is no equivalent, because a Polymarket Bot holds one market. trading_schedule, at the top level or on a rule, is Kalshi only. Use active_window for a one time window, or time_to_expiry conditions. edge (external data such as Coinbase prices and indicators) is not available on regular Polymarket. Kalshi and Polymarket US support it. See Edge Data. derived metrics are Kalshi custom only. rules[].orders and rules[].max_combined_price (composite orders) are Kalshi only. Use buy_yes or buy_no. entry_profit_offset, entry_stop_loss_offset, entry_profit_targets, entry_profit_min_time_to_expiry are Kalshi only. Write sell_yes or sell_no rules on price, the book fields or unrealized_pnl instead. See Advanced Kalshi Rules. Fields yes_position_size and no_position_size are Kalshi only. On Polymarket, position_size is YES and NO shares combined. Fields paired_best_bid_sum and paired_best_ask_sum are Kalshi only. You can compare yes_best_ask with no_best_ask using value_field. Field portfolio_position_count is Kalshi only: Polymarket never supplies it. risk.max_entries_per_market, risk.max_notional and active_window are rejected on built in strategies. They work with strategy: custom.25:T2119,Polymarket Market Selection This page covers the market block for regular Polymarket (platform: polymarket): each selector, which markets a Bot can trade, and what carries over when a rolling series moves to its next market. For every key and its allowed values, see All Polymarket parameters. Polymarket US uses different selectors; see Polymarket US market selection. A Polymarket Bot trades exactly one binary market at a time. You choose it with one concrete selector. All five below can be deployed; event_slug and query cannot. Selector What it pins Rolls to the next market? Market details the Bot knows slug One market No End date, tick, minimum size, volume (looked up once at start) condition_id One market No Same as slug yes_token_id + no_token_id One market No None: no end date, volume 0; minimum size from your YAML (default 5); tick from the exchange, else your YAML (default 0.01) series_slug The current market in a series Yes Looked up for each market recurring The current crypto Up/Down market Yes Looked up for each market event_slug, query Nothing Not deployable Discovery only If you set more than one selector, the Bot picks one in a fixed order when it starts: Try a Paper Run to observe your strategy on live prices with simulated money. Which markets can be traded The Bot accepts a market only if it has exactly two outcomes labelled Yes/No or Up/Down and it is not negative risk. Anything else makes the Bot exit at startup with a configuration error. That rules out markets whose outcomes are names (a team or a candidate) and grouped multi outcome markets such as temperature ranges or championship winners. A token pinned market skips this check, because the Bot never looks the market up. Make sure the IDs belong to a Yes/No or Up/Down market and are not swapped. market.slug The slug from a polymarket.com market URL. Use the market's slug, not the event's. The Bot looks the market up once at startup. From that it takes the YES and NO tokens, the end date (used by time_to_expiry), the tick size, the minimum order size, the fee flag and the market's volume. The Bot stays on this market. After the market closes it keeps looping with time_to_expiry at 0 and empty books until you stop it. Rolling crypto markets have a separate slug for every window (for example btc updown 15m plus a start time). Pinning one of those trades that single window only. Use series_slug or recurring to follow the series. If a token pair is also set, the token pair wins and the slug is only a label in logs. market.condition_id Pins a market by its condition ID (0x…). The Bot looks it up once at startup, exactly like slug, and never rolls over. market.yes_token_id and market.no_token_id The two outcome tokens, as long decimal strings. You must set both; one alone fails with Polymarket token selectors must include both market.yes_token_id and market.no_token_id. With both set, the Bot uses them as given and does not look the market up. That has consequences: There is no end date, so time_to_expiry is always 0. Rules on time_to_expiry never see the real time left, and pre_announcement_drift never enters. volume is always 0. The tick size comes from the exchange, or from market.tick_size (default 0.01) if that fails. The minimum order size comes from market.min_order_size (default 5). Outcome labels are not checked. Swapping the two IDs silently swaps YES and NO. If you pin by tokens, add the market's condition_id too. Live, the token pair still decides which market is traded, but the Bot uses the condition ID to list and cancel your orders and to read this market's trade history, which max_notional, max_entries_per_market and unrealized_pnl depend on. Without it the Bot only sees your most recent trades across all markets and can miss this market's buys. The budget and entry cap then undercount, and unrealized_pnl can be unavailable, so conditions on it stay false. A slug next to the tokens is only a label live. market.series_slug Follows a rolling Polymarket series, such as the crypto Up/Down markets. The Bot always trades the open market in the series that ends soonest. Rollover. From 10 seconds before the current market's end date, the Bot re checks the series on every loop. On the first check after the end date it switches to the next market. Next market not listed yet. That loop logs an error and the Bot tries again on the next loop. If no market is open when the Bot first starts, it exits. The slug is not checked against Polymarket when you save. A typo saves fine and the Bot exits at startup. If you also set recurring, the two must resolve to the same series. See Rolling series: what carries over for what resets when the Bot switches markets. market.recurring A shorthand for Polymarket's crypto Up/Down series. Studio turns it into a series_slug, and the Bot then behaves exactly as with series_slug. Asset (also accepts) 5m 15m 1h 4h 1d btc (bitcoin) btc up or down 5m btc up or down 15m btc up or down hourly btc up or down 4h btc up or down daily eth (ethereum, ether) eth up or down 5m eth up or down 15m eth up or down hourly eth up or down 4h eth up or down daily sol (solana) sol up or down 5m sol up or down 15m solana up or down hourly sol up or down 4h solana up or down daily xrp (ripple) xrp up or down 5m xrp up or down 15m xrp up or down hourly xrp up or down 4h xrp up or down daily doge (dogecoin) doge up or down 5m doge up or down 15m doge up or down hourly doge up or down 4h dogecoin up or down daily hype (hyperliquid) hype up or down 5m hype up or down 15m hype up or down hourly hype up or down 4h hype up or down daily bnb (binance) bnb up or down 5m bnb up or down 15m bnb up or down hourly bnb up or down 4h bnb up or down daily kind is optional and must be updown. asset and interval are required and case insensitive. Other assets, such as ADA or AVAX, are rejected. interval also accepts 5min, 5mins, 15min, 15mins, hour, hourly, daily and day. Spaces and hyphens are ignored, so 15 min works. 4h has no aliases; 30m, 60m, 4hour and weekly are rejected. Studio builds the series name from this table. Whether a given series has an open market at a given time is up to Polymarket. market.event_slug and market.query Studio can use these while it searches for a market with you, but you cannot deploy them. They fail validation with a message that they are discovery only, on their own or next to a concrete selector. Remove both once the market is chosen. A leftover search key next to a concrete selector is rejected too, because the Bot would refuse to start: market.neg_risk Optional, and only false is accepted. true fails with negative risk/multi outcome Polymarket markets are not supported. Setting false changes nothing at runtime: the Bot separately refuses any market Polymarket reports as negative risk. market.tick_size The fallback price increment: 0.1, 0.01, 0.001 or 0.0001. Any other value is rejected. The Bot always asks the exchange for the live tick first. Your value is used only for a token pinned market, and only if that request fails. For slug, condition_id and series selectors it has no effect. market.min_order_size The fallback minimum order size in shares, used only for a token pinned market (default 5). For other selectors the Bot uses the market's own minimum. Write it as a positive number, such as 5 or "5". Anything else, such as "abc" or 0, fails with Polymarket min_order_size must be a positive number. Rolling series: what carries over With series_slug or recurring, one Bot trades a chain of markets. This is what happens at the switch, using a 15 minute BTC series and a 15 second loop: Keep three things in mind: Limits and memory are per market. The max_notional budget and the max_entries_per_market count are read from the current market's trade history, so they start fresh in every market; neither is a lifetime limit for the series. Built in strategies also start each market with fresh memory: the cooldown, the fade count and price history, the momentum samples and the drift entry. Orders don't follow you. An entry still resting when the window closes belongs to the old market. Leftover shares stay where they are. When the Bot moves on, it does not sell or redeem shares still held in the old market. They settle with that market; manage them in your Polymarket account. Built in strategies also keep some of their own memory across the switch, such as a cooldown or a fade count. See Built in strategies on Polymarket.26:T2009,Polymarket Units, Rounding and Risk This page covers the units regular Polymarket (platform: polymarket) uses for prices, sizes, money and time, how the live Bot clamps and rounds order prices onto the market's tick, the market's minimum order size, and how each key in the risk block behaves here. For every key and its allowed values, see All Polymarket parameters. Units, ticks and rounding Quantity Unit Keys and fields Price Dollars per share, from 0 to 1. 0.62 is 62 cents, or a 62% implied probability. price_floor, price_ceiling, price, spread, the book fields, strategy thresholds Size Shares: outcome tokens that pay $1 each if they win. Studio sometimes calls them contracts. max_position, size, fade_size, position_size Money Dollars max_notional, balance (your available collateral), unrealized_pnl, volume (the market's lifetime traded volume) Time Whole seconds; durations such as "90s", "5m", "6h", "1d" in conditions (whole numbers only: "1.5h" is rejected; write "90m") loop.interval, cooldown, time_to_expiry max_position, loop.interval, max_entries_per_market and rules[].size are whole numbers. A fraction is dropped, so 10.9 acts as 10. Price ticks and rounding Every Polymarket market has a tick: 0.1, 0.01, 0.001 or 0.0001. Most use 0.01. Every order the Bot sends is a limit order, and before it goes out the live Bot: 1. clamps a buy's price into the allowed band: from the larger of price_floor and one tick, up to the smaller of price_ceiling and 1 minus one tick. A sell is only kept between one tick and 1 minus one tick; 2. rounds it onto the tick: buys round down, sells round up. Rounding never gives you a worse price, as long as price_floor and price_ceiling sit on the tick, but it can make a fill less likely. With a floor between ticks, such as 0.055 on a 0.01 tick, a buy at 0.055 rounds to 0.05, falls below the floor and goes out at 0.06 instead. The price bounds don't apply to sells, so an exit can always sell at the bid: with the best bid below price_floor, a sell goes out at that bid. A price_ceiling of 1 still stops a buy at 0.99 on a 1 cent tick. Order size and the market minimum Polymarket sets a minimum order size per market, usually 5 shares. Custom rules check it. A buy whose size ends up below the minimum after the max_position and max_notional clamps is skipped, and the Bot logs an entry_size blocked decision. An omitted size on a buy means 1 share. That is below the usual minimum, so the buy is always skipped. Set size to at least the market minimum. Built in strategies raise their orders to the minimum. A panic_fade fade_size, an observation_momentum order or a pre_announcement_drift entry below the minimum is sent at the minimum, and mean_reversion always buys the minimum. An order is never raised past max_position: if the minimum doesn't fit, the entry is skipped with an entry_size blocked decision. See Built in strategies on Polymarket. Fractional sizes are possible. The max_notional clamp divides dollars by price, so the Bot can send an order for, say, 13.33 shares. Risk keys on Polymarket Key Strategies Polymarket behavior max_position All Required. Measured as YES + NO shares in the current market. Enforcement differs by strategy; see risk.max_position. price_floor, price_ceiling All Clamp every live buy price. Sells aren't clamped. Also gate entries for most built ins. max_entries_per_market Custom only Counts buy orders from the exchange, per market. Fails closed. max_notional Custom only Dollar budget per market. Spent money is never released. Resets on each new market in a series. max_loss, max_portfolio_positions None Rejected on Polymarket. risk.max_position The most shares the Bot may hold in the current market, counting YES and NO together. It counts everything your wallet holds in that market, including shares you bought by hand. How it is enforced depends on the strategy: Strategy How max_position applies custom Each buy is cut to max_position minus position_size. A buy rule whose size is larger than max_position is rejected when you save. spread_capture Stops placing new quotes once holdings reach max_position, and leaves its last quotes resting. Several bid levels together can rest more than max_position. mean_reversion Order size is the market minimum. With max_position below it, entries are skipped. observation_momentum Caps total holdings: each order is cut to what still fits, and none is sent once holdings reach it. pre_announcement_drift Order size is max_position or 5, whichever is smaller, raised to the market minimum. With max_position below the minimum, it doesn't enter. panic_fade Not a holdings cap. The Bot buys fade_size, raised to the market minimum when max_position allows. If the Bot cannot read your balance, position_size reads 0 and the custom clamp widens rather than blocks. max_notional and max_entries_per_market fail closed instead: if the Bot cannot read your trade history, it skips the buy. risk.price_floor and risk.price_ceiling price_ceiling is required and must be above 0 and at most 1. price_floor is optional (default 0) and must be below the ceiling. Both are dollars per share. Live, they clamp every buy price, as described in Price ticks and rounding. With the floor at 0, the lowest live buy price is one tick. Sells aren't clamped, so a stop loss below the floor still sells at the bid. They also gate entries: panic_fade, observation_momentum and pre_announcement_drift enter only when the YES price is strictly between the floor and the ceiling. panic_fade also exits, at the bid, if the price drops below the floor. mean_reversion buys YES only when the price is above the floor, and buys NO only when the price is below the ceiling. spread_capture has no price gate. A floor above the market pushes its bid up, which can cross the book and trade at once unless post_only is true. Custom rules are not gated. A custom buy whose midpoint is above the ceiling is sent at the ceiling and may rest. risk.max_entries_per_market A hard cap on how many buy orders the Bot places in a market. Set it to 1 for a one shot strategy. Custom strategies only. Before each buy, the Bot counts entries already used from the exchange: distinct buy orders in this market's trade history, plus a held position if no buys are recorded yet, plus resting buy orders. If the count has reached the cap, the buy is skipped: Studio reports a max_entries_per_market guardrail and the decision log shows an entry_cap blocked decision. If the exchange history cannot be read, the buy is skipped too. When this cap is set, it replaces the default guard that skips a custom buy while any order is resting in the market. At 1 the count is exact. Above 1 it is conservative and may stop entries earlier than you expect. On series_slug and recurring the cap is per market: each new market of the series starts with its full allowance. See Rolling series: what carries over. risk.max_notional The total dollars the Bot may commit to buys in the current market. Custom strategies only. Spent is the price times size of every buy in this market's trade history, plus the unfilled part of resting buy orders. Fees are not included. Sells never free budget. Once spent, it is spent for that market. Each buy is cut to the remaining budget divided by the side's midpoint. If the budget is used up, the buy is blocked and Studio reports a max_notional guardrail. If the result is below the market minimum, the buy is skipped. If the history cannot be read, the buy is skipped. On series_slug and recurring, the budget resets in every new market. It is not a lifetime spend limit. When you save, a buy rule is rejected if size × price_floor is already larger than max_notional. For example, with max_notional: 10 and a midpoint of 0.50, the first buy is capped at 20 shares. After $4 is spent, the next buy is capped at 12 shares. At $10 spent, buys stop in that market. Deployment risk limits Regular Polymarket Bots don't read the deployment risk limits (max contracts per order, max open contracts, daily loss and the rest), so the deploy flow doesn't ask for them. The risk block in your strategy is what limits a Polymarket Bot, so set it as if it were the only limit.27:T281a,Polymarket Built in Strategies and Custom Rules This page covers how strategies run on regular Polymarket (platform: polymarket): how each built in strategy enters, prices, sizes and exits here, and what is specific to custom rules: the fields, the actions, how a custom buy is priced and sized, and what the validator checks when you save. For every key and its allowed values, see All Polymarket parameters. The behavior below describes live and Paper Bots, subject to the Paper differences at the end of this page. Built in strategies on Polymarket All six strategy types work on Polymarket, but the built ins run on Polymarket's own logic, so sizes, prices and exits differ from Kalshi. Parameter meanings and bounds are on Built in Strategies. This is how each one trades here: Strategy Enters when Order price Order size Exits spread_capture The YES spread is at least spread_floor. No price gate. Bids at the midpoint minus k × spread_floor/2, offers at plus the same, for k = 1 to order_count; bids clamped to floor and ceiling, offers capped at the ceiling The market minimum (usually 5) per level, not configurable. Each offer is capped at the YES you hold, so several levels together can offer more than you hold, and several bids together can rest more than max_position. No offers when you hold no YES. Sells through its offers. Each loop it cancels its own orders in the market and re quotes, except at max_position, where it stops quoting and leaves the last quotes resting. mean_reversion Flat, cooldown passed, nothing resting. YES if price is at or below entry_low; NO if at or above entry_high. The side's midpoint The market minimum; skipped if max_position is below it Sells everything when YES is within ±0.02 of exit_target. No stop loss. panic_fade YES is at least panic_threshold below its 5 minute high, fewer than max_fades so far, no fade open, nothing resting YES midpoint fade_size, raised to the market minimum Sells the YES the fade bought, at the YES bid, once price rises recovery_exit above the entry or drops below the floor observation_momentum YES moved at least momentum_threshold across the last lookback_periods samples. Buys YES on a rise, NO on a fall, while holdings are under max_position and nothing rests. The side's midpoint 1, 2, 3… (linear) or 1, 2, 4… (exponential), raised to the market minimum and cut to what fits under max_position Sells the side you hold, at its bid, when a qualifying move goes the other way pre_announcement_drift Once per market, when the end date is within entry_hours_before hours and outside the blackout The side's midpoint max_position or 5, whichever is smaller, raised to the market minimum Optional: sells what the entry bought when the blackout starts (exit_on_release) Things to know before you use a built in here: Entries rest at the midpoint. They are limit orders and may not fill. An entry that hasn't filled after two loops (at least 60 seconds) is cancelled. Regular Polymarket cancels by market, so any other order resting in the market is cancelled with it. Exits clear the market first. Before a built in sells, it cancels whatever is resting in the market: the unfilled rest of its own entry, or an earlier exit the bid has moved away from. Memory starts over in each market. On series_slug or recurring, each new market starts with a fresh mean_reversion cooldown, panic_fade price history and fade count, observation_momentum history and pre_announcement_drift entry. Everything also resets when the Bot restarts. panic_fade holds one fade at a time. Its exit sells the YES that fade bought, never shares you held before it, and the fade stays open until those shares are sold, even when a stop below the floor rests at the bid without filling. observation_momentum stops at max_position and sells what it holds when the move reverses. pre_announcement_drift needs an end date. With a token pinned market it never enters. rules on a built in are ignored on Polymarket, without an error. Write params as plain, unquoted values. A quoted number such as cooldown: "5m", or a quoted "false", no, off, yes or on for post_only or exit_on_release, is rejected. Use unquoted numbers and unquoted true and false. See The params block. Custom rules on Polymarket With strategy: custom, the Bot runs your rules every loop, top to bottom. The first rule whose conditions match runs its action, and nothing else happens that loop. The full rule syntax is on Custom Rules. This section covers what is specific to Polymarket. Rule keys you can use here: name, when, action, size. At least one rule must be an exit: sell_yes, sell_no, sell_all or cancel_all. A cancel_all rule alone passes this check but never sells anything; add a sell rule if you want the Bot to close positions. Put exits above guards. A skip or cancel_all rule that matches first also blocks the exits below it. Do not use a double quote (") in a rule name or selector value, and do not end one with a backslash. The strategy saves, but the Bot fails to start. Fields Twelve fields work on Polymarket: Field On Polymarket price YES midpoint. Falls back to the ask, the bid, then the last trade; 0 if none. Always the YES side, even in a buy_no rule. spread YES ask minus YES bid. A missing side counts as bid 0 or ask 1, so the spread can read 1. volume The market's lifetime volume in dollars, read when the market is looked up (refreshed only at a series rollover). 0 for token pinned markets. time_to_expiry Seconds until the market's end date; 0 if unknown or past, and always 0 for token pinned markets. Compare with durations such as "90s", "5m", "6h". position_size YES + NO shares your wallet holds in the current market unrealized_pnl Dollars: held shares valued at the best bid, minus their cost and fees from this market's trade history (from paper fills on a Paper Bot). 0 when flat. Unavailable when the position can't be valued (see below). balance Available collateral in dollars order_count Your open orders in this market, buy and sell, both tokens yes_best_bid, yes_best_ask Best bid and ask in the YES token's book no_best_bid, no_best_ask Best bid and ask in the NO token's own book YES and NO are separate tokens with separate books. Live, the Bot never works out a NO price as 1 minus the YES price: Empty books. A book field for an empty side has no value. Every comparison with it is false, whatever the operator, including !=, and on either side of a value_field comparison. If the NO book cannot be read on a loop, the NO fields have no value for that loop and the Bot logs a no_book error. If the YES book cannot be read, the whole loop is skipped. unrealized_pnl can be unavailable. It is only worked out when one of your rules reads it. If a side you hold has no bid, or, on a live Bot, your holdings can't be matched to this market's recent trade history or that history can't be read, unrealized_pnl is unavailable for that loop: conditions on it are false whatever the operator, including !=, the Bot logs an unrealized_pnl error, and your other rules, exits included, still run. A P&L exit therefore can't fire until the position can be valued again, while a price exit doesn't depend on it. Keep this in mind for thin markets and for shares you moved in or out by hand. A Paper Bot values its position from its own paper fills, so there only a missing bid makes unrealized_pnl unavailable. Actions Action Order price Size buy_yes YES midpoint, rounded down to the tick size (1 if omitted), then clamped (see How a custom buy is priced and sized) buy_no NO midpoint, rounded down to the tick Same as buy_yes sell_yes YES best bid. With no bid, the YES ask (or last trade), so the order rests. size, or all YES held if omitted sell_no NO best bid. With no bid, the NO ask (or last trade), so the order rests. size, or all NO held if omitted sell_all Each side's best bid (the ask if there is no bid) Everything held, both sides; size is ignored cancel_all none Cancels this Bot's open orders in this market skip none Does nothing, but stops later rules from running this loop sell_all sells everything your wallet holds in this market, including shares you bought by hand. cancel_all cancels only orders this Bot placed: Polymarket orders carry no client id, so the Bot keeps the id of every order the exchange accepts from it, and never cancels your manual orders or another Bot's. An order from before the Bot started keeping ids is not cancelled. How a custom buy is priced and sized On Kalshi a custom buy takes the best ask. On Polymarket it rests at the side's midpoint, so it can sit unfilled while the market moves. Without max_entries_per_market, any resting order in the market blocks the next buy; a cancel_all rule is how you clear a stale bid. This is the path every buy_yes and buy_no takes after its rule fires: The position, budget, minimum size and price steps are covered in more detail under risk.max_position, risk.max_notional, Order size and the market minimum and Price ticks and rounding. What the validator checks Besides field and action names, the validator checks rule behavior when you save. It rejects: conditions that can never match, or entries that match in every state; rules that earlier rules make unreachable; exit sets that together fire in every held state, and an exit whose only condition is on position_size and that fires whenever you hold anything (such as position_size 0); entries and exits that would alternate on an unchanged market (add bounds to the entry so the exit cannot fire straight after it); buy sizes that max_position or max_notional can never allow. It does not know the market minimum, so a buy with no size saves but never trades. Warning: Paper Bots can differ from live Bots. Paper orders skip tick rounding and the price clamp, and pay no fees by default, so paper results can differ from live near the price bounds. Custom paper buys still respect the market's minimum order size. max_notional counts only resting paper buys, not filled ones, so on a Paper Bot it binds less than live and max_position is the cap that holds. max_entries_per_market counts a held position and resting buys, not completed paper trades, so after a round trip back to flat a Paper Bot can buy again where a live Bot would stop.28:Tcec,Polymarket Active Window, Paper Runs, Fees and Location This page covers four topics for regular Polymarket (platform: polymarket) strategies: the one time active_window, Paper Runs, how fees are charged, and where live Polymarket trading is not available. For every key and its allowed values, see All Polymarket parameters. active_window A one time wall clock window for a custom strategy. Set start, end or both as RFC 3339 timestamps with a timezone offset, for example 2026 10 04T09:00:00 04:00. end must be after start. State When What the Bot does Waiting Before start Nothing. No rules run, exits included. Active From start until end Runs your rules every loop.interval. Ended At and after end Cancels this Bot's resting buys in the current market once (retrying next loop if that fails), then keeps running your rules with entries blocked: a matching buy rule is skipped, and sells and cancel_all still work. Its resting sells, your manual orders and other Bots' orders stay. A series Bot stops rolling over. An end that is already past still saves; the Bot then runs that end of window cancel as soon as it starts and never enters. Positions are not sold at end on its own: shares are closed only by your exit rules, and whatever they don't close settles with the market. Paper Runs To test behavior from now on, open the Paper tab and choose Start Paper Run. A Paper Run uses live prices with simulated money; it does not replay past data or establish historical performance. Paper fills are simulated, not submitted orders or confirmed exchange fills. See Paper Bot differences. Fees Polymarket charges trading fees on some markets. Live, Polymarket charges them. The Bot does not add its own fee model. unrealized_pnl subtracts the fees recorded in your trade history; max_notional counts price times size only. Paper Bots pay no fees by default. Location restrictions Live Polymarket trading is not available everywhere. Studio checks your location whenever you deploy, redeploy or recover a regular Polymarket Bot, Paper Bots included, and refuses with "Polymarket live trading is not available from your current location" from: the United States, the United Kingdom, France, Germany, Italy, Belgium and Australia; Belarus, Burundi, the Central African Republic, Cuba, the Democratic Republic of the Congo, Ethiopia, Iran, Iraq, Lebanon, Libya, Myanmar, Nicaragua, North Korea, Russia, Somalia, South Sudan, Sudan, Syria, the US Minor Outlying Islands, Venezuela, Yemen and Zimbabwe; Brazil, New Zealand and Slovakia; Poland, Singapore, Thailand and Taiwan, where Polymarket allows closing positions only; Alberta, British Columbia, Ontario and Quebec (Canada), and Crimea, Donetsk and Luhansk (Ukraine). Studio follows restrictions on opening orders through the API, including API close only locations because a Bot can open new positions. Restrictions that apply only to the Polymarket website in Ireland, Japan, Malta, the Netherlands and South Korea do not block Studio API Bots. A live Bot also checks its runner's location when it starts and exits without placing orders if Polymarket reports a restriction, except for those website only locations. Polymarket's rules can change; its API geographic restrictions are the policy source. If you are in the United States, use Polymarket US.29:T14a7,Polymarket Example Strategies This page collects complete example strategies for regular Polymarket (platform: polymarket): custom rules on rolling crypto series and on pinned markets, then the built in panic_fade, mean_reversion and pre_announcement_drift. For what each key does, see All Polymarket parameters. Each example below saves and compiles as shown. The slugs, IDs and numbers are placeholders chosen to show a shape. Swap in your own market and choose your own values. The examples are not recommendations, and automated strategies can lose money; see Risk & Limits. In the crypto Up/Down examples, Up is YES and Down is NO. Try these strategies in a Paper Run on live prices with simulated money. Rolling BTC 15 minute series (custom, recurring) Follows every 15 minute BTC Up/Down market. It buys Up only in the last one to five minutes, when Up is priced 0.60 to 0.75 with a tight spread, then takes profit or cuts the loss on the YES price. Exits come first, because the first matching rule wins. The $8 max_notional applies to each 15 minute market separately and starts fresh at each rollover: about two 5 share entries at up to 0.75. max_entries_per_market would also work on a series, where it counts each market's entries separately. This example relies on the position_size == 0 gate instead. Shares still held at the close settle with that market. SOL 5 minute series with dollar P&L exits (custom, series_slug) Names the series directly. It buys Down when Up is priced 0.72 to 0.85, exits on dollar unrealized_pnl with sell_all, and cancels an unfilled entry just before the close. price is the Up (YES) midpoint even though the rule buys Down; the order goes out at the Down (NO) midpoint. The $4 budget is per 5 minute market. The dollar exits need a value for unrealized_pnl. If the Down book has no bid, unrealized_pnl is unavailable and neither exit can fire until a bid returns. See Fields. One shot NO on a pinned market (custom, slug, NO book fields) Pins one market, buys NO once using the NO book, then takes profit or stops out with sell_no. max_entries_per_market: 1, max_notional and an active_window bound it. The entry's no_best_bid bounds (0.15 to 0.55) keep the exits from firing straight after the entry. Without them the validator rejects the rules as alternating (see What the validator checks). 20 shares at a NO midpoint of at most 0.35 cost at most $7, inside the $10 budget. At end, the Bot cancels its resting buy and stops entering. Its sell_no take profit and stop keep running, so a position is still closed by them; otherwise it is held to resolution. The slug is enough. Adding token IDs would switch off the market lookup and set time_to_expiry and volume to 0. See market.yes_token_id and market.no_token_id. Guarded YES dip buyer (custom, book fields, skip, cancel_all) Shows rule order, a skip guard, a cancel_all for stale bids and a value_field comparison. The take profit sits above the skip guard. A guard placed first would also block the exit. pull_stale_bids clears a resting midpoint bid once YES has moved above 0.40, because a resting order blocks the next buy (see How a custom buy is priced and sized). The $5 budget is never released. Later round trips are cut to what remains and stop once the cut falls below the market minimum. Token pinned market (built in panic_fade) Pins a market by condition ID and both token IDs, with explicit market metadata. It buys YES once after an 8 cent drop from the 5 minute high and sells on a 4 cent rise or a fall below the floor. The IDs are placeholders; copy the real ones from the market. With both token IDs the Bot skips the market lookup, so time_to_expiry and volume read 0; panic_fade reads neither. tick_size is used only if the exchange's tick lookup fails, and min_order_size sets the smallest order the Bot sends. They are shown here as the fallbacks a token pinned market uses. The condition_id next to the tokens lets the Bot list and cancel your orders in this market. panic_fade doesn't cap holdings at max_position; it is set equal to fade_size here for clarity. max_fades: 1 makes this a single fade. recovery_exit sets the live take profit distance above the fade entry price. ETH hourly mean reversion (built in, recurring) Buys Up when its price is at or below 0.35, buys Down when Up is at or above 0.65, and sells near 0.50. Live order size is the market minimum, usually 5 shares. The exit fires only while Up is between 0.48 and 0.52. Otherwise the position rides to the hourly settlement. There is no stop loss. cooldown: 60 explicitly sets the minimum seconds between entry attempts. Pre close drift on a pinned market (built in pre_announcement_drift) Buys YES once in the 12 hours before the market's end date, then sells that YES when the final 30 minute blackout starts. The market's end date stands in for the announcement time, so pin the market by slug, condition_id or a series, never by token IDs alone. Size is 5 shares (max_position or 5, whichever is smaller), bought at the YES midpoint. If the entry doesn't fill within two loops it is cancelled and placed again while the window is open. A restart forgets the entry, so it can enter again. blackout_minutes_before is required; 0 means no blackout, and then exit_on_release never fires.2a:T3cbd,Polymarket US Strategy Reference This section covers every strategy parameter for platform: polymarket_us. Polymarket US is a separate exchange from regular (international) Polymarket. It has its own markets, accounts and API keys. A Polymarket US Bot trades one market on your own Polymarket US account. The YAML has the same shape as on the other venues: version, platform, strategy, market, risk, loop, then params for a built in strategy, or rules (and optionally edge) for a custom one. Polymarket US supports only part of the strategy language, though. This page lists every parameter Studio accepts, what it rejects, and how backtesting, paper mode and credentials work. How the Bot picks its market and places orders, how each strategy behaves, and complete examples are on the pages listed under In this section. In Polymarket US terms, buying YES is going long and buying NO is going short. Every price in the YAML is a dollar price per contract between 0 and 1, and it refers to the YES price unless a section says otherwise. Note: Turbine is not a financial advisor. The numbers in this section are small, illustrative values that show how parameters behave. They are not recommendations of markets, sizes or thresholds. In this section Polymarket US Markets, Risk and Execution: Choosing the market with slug, event_slug or query; max_position, the price floor and ceiling, and loop.interval; the deployment risk limits; and how entries and exits are priced and checked before they're sent. Polymarket US Strategies and Edge Data: How each built in strategy behaves on Polymarket US; custom rule fields, actions, validator checks and the decision log; and the edge data providers, including what happens when a feed goes stale. Polymarket US Example Strategies: Complete strategies that pass Studio's checks: NWS weather (with a rejected first draft and its fix), Coinbase MACD momentum, the FOMC calendar, a dip buyer with no outside data, and the spread_capture, mean_reversion and pre_announcement_drift built ins. How Polymarket US differs If you know the Kalshi or Polymarket pages, these are the differences that matter most: One fixed market per Bot. You pick it with market.slug (or, less predictably, event_slug or query). There is no rolling series: when a dated market closes, the Bot does not move on to the next one. Fewer risk keys. Only max_position, price_floor and price_ceiling. There is no max_loss, max_notional, max_entries_per_market, active_window or trading_schedule. Built in strategies can't have rules. Use strategy: custom if you want rules. Exits are sell_all only. sell_yes and sell_no, which Kalshi and regular Polymarket accept, are rejected here, and so are the order book fields (yes_best_bid and friends). Edge data works, unlike on regular Polymarket: Coinbase, NWS weather and the economic calendar, in custom strategies. Entries are resting limit orders at the last trade price, where Kalshi custom entries price at the current ask. Exits are market orders for your whole position, split into orders that each fit the deploy dialog's Max contracts per order. See Order pricing and execution. No backtesting. Kalshi supports historical backtests. You can run a Bot in paper mode, with the gaps described in Paper mode. Your own API keys. The Bot trades with the Polymarket US API Key ID and Secret Key you enter when you deploy, not the wallet based credentials regular Polymarket uses. All Polymarket US parameters Every key Studio accepts for platform: polymarket_us is listed below. A linked parameter name goes to the sub page that explains how it behaves on Polymarket US. Keys that Studio rejects are listed under Not available on Polymarket US. Document keys Parameter Type Default Allowed values What it does version integer required 1 Strategy language version. platform string required polymarket_us Selects Polymarket US. Case doesn't matter. A Polymarket US Studio session refuses a strategy that names another platform, and that refusal also clears the strategy the session had saved. Start a new session to use another venue. strategy string required spread_capture, mean_reversion, panic_fade, observation_momentum, pre_announcement_drift, custom A built in strategy or custom rules. strategy_name string none any text; Studio trims it to 80 characters Display name. No effect on trading. strategy_name_origin string generated user, generated, curated (anything else, including legacy, is saved as generated) Where the name came from. Metadata only. name string none any Old key, accepted and ignored. Use strategy_name. Market, risk and loop Parameter Type Default Allowed values What it does market.slug string none an exact Polymarket US market slug The market the Bot trades. Set one of slug, event_slug or query. market.event_slug string none a Polymarket US event slug Trades the first open market in that event, chosen once at startup. market.query string none free text Trades the first open market a search returns, chosen once at startup. risk.max_position integer (contracts) required whole number, 1 or more Sizes built in orders and caps a custom rule's size. risk.price_floor number ($) 0 0 or more, below 1 and below price_ceiling Lowest price the Bot trades at. Custom entries are clamped up to it. risk.price_ceiling number ($) none (required in practice) above 0, at most 1, above price_floor Highest price the Bot trades at. Custom entries are clamped down to it. loop.interval integer (seconds) required 10 or more Seconds between strategy runs. Built in strategy params These go under params:. Each one applies only to the strategy named at the start of its description. Parameter Type Default Allowed values What it does params.spread_floor number ($) required above 0 spread_capture: quote only when ask − bid is at least this; also sets quote spacing. params.order_count integer required whole number above 0 spread_capture: quote levels on each side. params.post_only boolean false true, false spread_capture: maker only quotes. params.refresh_on_fill boolean false any Accepted, no effect on Polymarket US. params.entry_low number (YES $) required a number below entry_high mean_reversion: buy YES at or below this price. params.entry_high number (YES $) required a number above entry_low mean_reversion: buy NO when YES is at or above this price. params.exit_target number (YES $) 0.5 a number mean_reversion: exit when YES is within 2¢ of this. params.cooldown integer (seconds) 60 whole number, 0 or more mean_reversion: minimum time between entry attempts. params.panic_threshold number ($) required above 0 panic_fade: drop from the 5 minute high that triggers a buy. params.fade_size integer (contracts) required whole number above 0 panic_fade: contracts per fade, and per exit. params.recovery_exit number ($) 0.04 a number panic_fade: rise above the fade price that closes it. params.max_fades number 3 a number panic_fade: fades allowed per Bot run. params.recovery_target number none any Accepted, no effect on Polymarket US. Use recovery_exit. params.lookback_periods integer (loops) required whole number, 2 or more observation_momentum: window length, counted in loops. params.momentum_threshold number ($) required above 0 observation_momentum: minimum price move over the window. params.position_scale string linear exponential; anything else means linear observation_momentum: how order size grows. params.entry_hours_before integer (hours) required whole number above 0 pre_announcement_drift: entry window opens this long before close. params.blackout_minutes_before integer (minutes) required whole number, 0 or more pre_announcement_drift: no entries in these final minutes. params.drift_direction string auto bullish, bearish; anything else means auto pre_announcement_drift: which side to buy. bullish buys YES, bearish buys NO, auto buys YES below 0.50 and NO at 0.50 or above. params.exit_on_release boolean false true, false pre_announcement_drift: sell when the blackout starts. params.position_size any none any Not read on Polymarket US. Order size comes from the strategy (see risk.max_position). Write params as plain, unquoted values: a quoted number such as entry_low: "0.2" or cooldown: "60" is rejected, and so is a word where a number belongs (exit_target: half) or a quoted boolean such as post_only: "false". See The params block. Custom rules and edge data Parameter Type Default Allowed values What it does rules list required for custom at least 1 rule, including a sell_all or cancel_all rule Ordered if then rules. The first match each loop wins. Rejected on built in strategies. rules[].name string required non empty text Label in logs and decisions. rules[].when.all or rules[].when.any list of conditions required (exactly one) all (every condition true) or any (at least one true) The rule's trigger. [rules[].when.[].field](/docs/strategy reference/polymarket us/strategies#condition fields) string required price, spread, volume, time_to_expiry, position_size, unrealized_pnl, balance, order_count, edge. . The value the condition reads. rules[].when.[].op string required , =, ==, != Comparison. Always quote it: op: " ". rules[].when.[].value number, or duration string one of value or value_field a plain number; for time_to_expiry a string like "30m", "6h", "1d" What to compare against. Numbers must not be quoted. rules[].when.[].value_field string one of value or value_field any numeric field above Compare against another live value, e.g. MACD against its signal line. [rules[].action](/docs/strategy reference/polymarket us/strategies#actions) string required buy_yes, buy_no, sell_all, cancel_all, skip What happens when the rule matches. [rules[].size](/docs/strategy reference/polymarket us/strategies#actions) integer (contracts) 1 0 to risk.max_position; decimals are dropped Contracts per entry. Ignored for other actions. edge map of aliases none up to 8 aliases; lowercase names that start with a letter (letters, digits, _; 32 characters max) Outside data for custom rules. edge. .provider string required coinbase, nws, economic_calendar The data source. edge. .symbol, .station or .event string required (the one that matches the provider) Coinbase symbol like BTC USD; NWS station like KLGA; calendar event of FOMC, CPI or FOMC,CPI What to fetch. edge. .fields list required field names from the provider's catalog The only fields rules may read from this alias. edge. .refresh duration Coinbase 5s, NWS 5m, calendar 15m at least 1s (Coinbase; 5s with candle fields), 60s (NWS), 5m (calendar) How often the data is fetched again. Deployment risk limits such as Max contracts per order are not YAML keys. Studio pre fills them in the deploy dialog from your strategy, and you confirm or change them there; see Deployment risk limits. Not available on Polymarket US Rejected when you save Studio refuses a Polymarket US strategy that uses any of these. Key or feature Use this instead on Polymarket US risk.max_loss There is no loss based stop on Polymarket US. Use price based sell_all exits and your deployment risk limits. risk.max_notional The deployment risk limits Max dollars per order and Max daily notional traded. risk.max_entries_per_market Guard entries with position_size == 0. For panic_fade, max_fades. risk.max_portfolio_positions Not needed: each Bot trades one market. active_window time_to_expiry conditions, or deploy and stop the Bot at the times you choose. trading_schedule (whole strategy or per rule) time_to_expiry conditions, or economic_calendar edge data for event timing. derived (for example distance from strike) Compare the edge field against a fixed number in the rule. rules[].orders and rules[].max_combined_price buy_yes and buy_no entries. entry_profit_offset, entry_stop_loss_offset, entry_profit_targets, entry_profit_min_time_to_expiry sell_all rules with price conditions. Actions sell_yes and sell_no sell_all, which sells whichever side you hold. Fields yes_best_bid, yes_best_ask, no_best_bid, no_best_ask price and spread. Fields paired_best_bid_sum, paired_best_ask_sum price and spread. Fields yes_position_size, no_position_size position_size (contracts held on either side). Field portfolio_position_count Not needed: each Bot trades one market. Kalshi selectors market.ticker, market.event_ticker, market.series_ticker, market.selection market.slug. Polymarket selectors market.series_slug, market.recurring, market.condition_id, market.yes_token_id, market.no_token_id, market.neg_risk, market.tick_size, market.min_order_size market.slug. rules on a built in strategy strategy: custom. The four risk keys are rejected when set above 0. A value of 0 means off and is accepted, but it does nothing. Backtesting isn't offered for Polymarket US either; see Backtesting. Accepted but not supported These save without an error but don't work on Polymarket US. Avoid them. params.refresh_on_fill, params.recovery_target and params.position_size are ignored. An edge block on a built in strategy is ignored. Only custom rules read edge data. Typos inside params or an edge alias. Unknown keys there are silently ignored, so params.cooldwn does nothing. Unknown keys inside market, risk and loop, such as risk.max_loss_usd or loop.jitter, are rejected, as are unknown top level keys and unknown rule keys. Double quotes or a trailing backslash in market.slug, event_slug, query or a rule name. They pass Studio's checks but stop the Bot at startup. Backtesting, paper mode and credentials Backtesting Backtesting isn't available for Polymarket US. Studio refuses backtests for Polymarket US strategies, and Deep Research is not yet supported for Polymarket US. Paper mode is the only way to run a Polymarket US Bot without real orders. Paper mode You can deploy a Polymarket US Bot in paper mode. It is the same Bot, reading live Polymarket US market data, but orders, fills, positions and balance are simulated. The simulated balance starts at $1,000 by default. Your deployment risk limits still apply, and the Bot still needs your API keys, because it signs its market data requests. A limit order that crosses the live book fills at once if the visible depth within your limit covers the whole order. Otherwise it rests, and fills in full once the opposite best price moves strictly through your limit. Post only orders that would cross are rejected. Simulated fees are 0. Market orders, which sell_all and the built in exits use, fill against the whole visible book at once if its depth covers the order, and are rejected otherwise. They never rest. Note: unrealized_pnl reads 0 in paper mode. Credentials A Polymarket US Bot trades on your Polymarket US account with the API Key ID and Secret Key you create in the Polymarket US developer portal (polymarket.us/developer). Studio asks for them in the deploy dialog; never paste them into chat. Turbine's own account never trades for you, and buying power comes from your Polymarket US balance. These are not regular Polymarket credentials. There is no wallet key. Your keys are shared by every Polymarket US Bot, and every Kalshi + Polymarket US arbitrage Bot, on your runner. Entering new keys replaces them for all of those Bots. Other Bots switch to the new keys the next time they restart. On a redeploy you can keep the keys already saved. A revoked or mistyped key makes every request fail, so the API error breaker trips after 3 errors in 5 minutes (the defaults) and new orders stop; the breaker retries after each 5 minute cooldown and trips again while the key keeps failing.2b:T1b7d,Polymarket US Markets, Risk and Execution This page covers the settings that decide where and how much a platform: polymarket_us Bot trades: the market selector, the three risk keys Polymarket US accepts (max_position, price_floor and price_ceiling), loop.interval, and the deployment risk limits you set when you deploy. It also explains how the Bot prices entries and exits, and the checks every order has to pass. For every accepted key at a glance, see All Polymarket US parameters; for the keys Studio rejects, see Not available on Polymarket US. Market selection A Polymarket US Bot always trades exactly one market. Set one selector. If you set more than one, slug wins, then event_slug, then query. All three pass Studio's checks and can be deployed. Studio's AI is set up to save a concrete market.slug, which is the predictable choice. market.slug The exact market the Bot trades, for example a daily temperature contract. Nothing is looked up at startup: every order, position read and open order read uses this slug. The slug isn't checked when you save. A wrong slug shows up once the Bot runs, as "market ... is not active" or "market missing" errors. No rollover. When a dated market closes, the Bot stays pointed at it and every order is refused. To trade the next market in a series, update the slug and redeploy. market.event_slug When the Bot starts, it searches open events, takes the one whose slug matches exactly, and trades that event's first active market. It chooses once and keeps that market until it restarts. In an event with several markets, "first" depends on how Polymarket US orders them, and may not be the outcome you meant. If no open market matches, the Bot logs a configuration error and stops before its first loop. On regular Polymarket, event_slug alone is rejected. On Polymarket US it's accepted. market.query A free text search. At startup the Bot trades the first active market in the results. It doesn't pick the most liquid one, and results can change between restarts, so treat it as a discovery tool rather than something to deploy. If the search finds no open market, the Bot logs a configuration error and stops before its first loop. Note: The rolling daily selector (market.recurring) exists only for the Polymarket US leg of an arbitrage strategy. A single venue Polymarket US strategy rejects it. Risk and loop risk.max_position A whole number of contracts, 1 or more. Decimals are dropped: 2.5 becomes 2. How it's used depends on the strategy: Strategy What max_position does on Polymarket US spread_capture Stops placing quotes while you hold max_position or more. mean_reversion Each entry is min(max_position, 10) contracts. panic_fade Not used. fade_size sets the size. observation_momentum Caps each order's size and your total position: an order is cut to what still fits. pre_announcement_drift The entry is min(max_position, 5) contracts; the release exit sells what the entry bought. custom A rule's size can't be larger. On every strategy, the running Bot also refuses a buy that would take the contracts you hold plus your resting orders in the market past the lower of max_position and the deploy dialog's Max open contracts (open contracts would be 6, exceeding risk.max_position=5). Sells are never capped. Note: The deploy dialog's Max contracts per order caps every order. Studio pre fills it from your strategy's largest single order: the biggest rule size (1 when omitted), min(max_position, 10) for mean_reversion, max_position for observation_momentum, min(max_position, 5) for pre_announcement_drift, fade_size for panic_fade and 1 for spread_capture. A larger entry is refused; sell_all and the built in exits are split to fit. risk.price_floor and risk.price_ceiling price_floor defaults to 0 and must be below 1. price_ceiling must be above 0, at most 1, and above the floor. Leaving the ceiling out is an error. What they do depends on the strategy: Custom entries: the price of the side you buy (the YES price for buy_yes, 1 − YES for buy_no) is clamped into the range. The trade still happens; only the limit price moves. See Entries. mean_reversion: buys YES only when price_floor Entries Every entry (buy_yes, buy_no and the built in strategies' buys) is a good till cancel limit order for a whole number of contracts: 1. Price. The Bot uses the last trade price for YES. If there is none, it uses the current price, then the midpoint of the best bid and offer. For buy_no the NO price is 1 − that YES price. (spread_capture is the exception: it prices its quotes around the midpoint.) 2. Clamp. Custom entries clamp that price into [price_floor, price_ceiling]. 3. Round. The price is sent on a 1 cent grid. 4. Rest. The order doesn't chase the offer. If nobody trades at your limit, it rests until it fills or something cancels it. A custom entry is also skipped while any order is resting in the market, and when your buying power doesn't cover it. Pair entries with a cancel_all rule if an unfilled order should not wait forever. Exits sell_all and the built in exits sell your whole position on the side you hold with market orders (panic_fade and pre_announcement_drift sell only what their own entry bought, on its side): A position larger than Max contracts per order is split into several orders of at most min(40, Max contracts per order) contracts, sent one after another. An exit needs a bid to sell into, not a two sided book. A sell that only reduces your position isn't held back by the API error breaker or Max daily notional traded. If a piece is refused or rejected, the exit stops there; the rest is retried on the next loop if the rule still matches. A rejected order is logged as rejected (order_rejected), never as placed. cancel_all, and spread_capture's refresh, cancel only this Bot's open orders. Polymarket US orders carry no client id, so the Bot remembers the id of every order the exchange accepts from it; the memory survives restarts and redeploys, but not stopping the Bot. Orders you placed by hand and other Bots' orders are never cancelled. In paper mode every paper order is the Bot's own. Checks before every order Before sending any order, the Bot confirms all of the following. If one fails, the order is refused and that loop ends with an error in the Bot log. Check Buys Sells The API error breaker hasn't tripped Yes Only if the sell doesn't simply reduce your position Quantity is within Max contracts per order Yes Yes The market is active and not closed, settled or expired Yes Yes The book is two sided: 0 < best bid < best offer < 1 Yes A bid between 0 and 1 is enough The order price is strictly between 0 and 1 Yes Yes Your position and open orders in the market can be read Yes Yes Held + resting + new contracts within Max open contracts Yes No Side price × contracts within Max dollars per order Yes No Buying power covers the order Yes No Today's traded notional stays within Max daily notional traded Yes Only if the sell doesn't simply reduce your position These checks can't be turned off.2c:T207a,Polymarket US Strategies and Edge Data This page covers the two ways to write a platform: polymarket_us strategy (a built in strategy tuned through params, or strategy: custom with your own rules) and the edge data (Coinbase, NWS weather and the economic calendar) that custom rules can read. Limits such as Max contracts per order and Max open contracts are the deployment risk limits you set when you deploy, and how orders are priced is covered in Order pricing and execution. For every parameter at a glance, see All Polymarket US parameters. Built in strategies on Polymarket US The five built in strategies work on Polymarket US, with fixed logic you tune through params. Each one has its own page under Built in Strategies that explains it in general. This section covers what's specific to Polymarket US. A built in strategy can't also have rules: Studio rejects it with "Polymarket US built in strategies do not support top level rules; use strategy: custom to define rules". An edge block on a built in strategy is ignored. Strategy Required params Optional params (default) Order size on Polymarket US spread_capture spread_floor, order_count post_only (false) 1 contract per quote mean_reversion entry_low, entry_high exit_target (0.5), cooldown (60) min(max_position, 10) panic_fade panic_threshold, fade_size recovery_exit (0.04), max_fades (3) fade_size observation_momentum lookback_periods, momentum_threshold position_scale (linear) grows 1, 2, 3… capped at max_position pre_announcement_drift entry_hours_before, blackout_minutes_before drift_direction (auto), exit_on_release (false) min(max_position, 5) spread_capture Each loop, if ask − bid is less than spread_floor, the Bot cancels its own open orders in the market and stops there. Otherwise it cancels them and places order_count levels of 1 contract quotes: a YES bid at mid − (spread_floor ÷ 2) × level (never below the floor) and a YES offer at mid + (spread_floor ÷ 2) × level (never above the ceiling). For example, with a bid of 0.45, an offer of 0.55 and spread_floor: 0.04, level 1 quotes 0.48 / 0.52, level 2 quotes 0.46 / 0.54, and level 3 quotes 0.44 / 0.56. Every resting quote counts toward Max open contracts, bids and offers alike, and Studio pre fills that limit from max_position. The bid at level 2 already counts level 1's two quotes, so it needs a limit of at least 3 plus what you hold; the bid at level 3 needs at least 5 plus what you hold. A refused bid ends that loop, so the quotes after it aren't placed. Use order_count: 1, or raise Max open contracts to about twice order_count when you deploy. Once you hold max_position or more, the Bot stops quoting, but it doesn't cancel quotes that are already resting. The offer is a YES sell placed even when you hold no YES. Check your positions closely after the first fills. In paper mode, an offer that fills while you hold no YES opens a NO position. It cancels only its own orders each loop: the ones the exchange accepted from this Bot (see Exits). Orders you placed by hand and other Bots' orders stay resting, but they still count toward Max open contracts. post_only: true makes quotes maker only, so a quote that would trade immediately isn't placed as a taker order. mean_reversion When you hold nothing, the cooldown has passed and no order is resting, the Bot buys YES if price_floor Condition fields Field Unit What it reads on Polymarket US price $ (YES) Last trade price, then current price, then the book midpoint. 0 if none is available. spread $ Best offer − best bid. A missing bid counts as 0 and a missing offer as 1. volume number The market's volume as reported by Polymarket US, as a whole number. time_to_expiry duration Time until the market's end date. Compare with a string such as "30m", "6h" or "1d". It reads 0 when the market has no end date, so time_to_expiry . varies A numeric field you declared under edge. position_size and order_count work per account and market, so orders you place by hand, or another Bot on the same market, are included. cancel_all cancels only this Bot's orders. time_to_expiry values take one whole number and one lowercase unit: s, m, h or d. "1h30m", "6H" and a bare number are rejected. Actions Action What it does on Polymarket US buy_yes Good till cancel limit buy of YES at the clamped last trade price. Skipped while any order rests in the market or buying power is short. buy_no The same for NO, at 1 − the YES price. sell_all Market sell of your whole position on the side you hold. Refused if the position is larger than Max contracts per order. cancel_all Cancels this Bot's open orders in the market; your manual orders and other Bots' orders stay. It satisfies the "needs an exit" check, but it never closes a position. skip Does nothing and stops checking rules for this loop. Useful as a guard above your entries. size sets contracts per entry. Omitting it (or size: 0) means 1, and decimals are dropped (1.9 becomes 1). A negative size or one larger than risk.max_position is rejected, and above 1 it also needs a higher Max contracts per order when you deploy. What the validator checks Studio rejects a custom strategy that: has no sell_all or cancel_all rule ("custom strategy requires at least one rule with action sell_all or cancel_all"), has exit rules that together fire in every state where you hold a position ("exit rules collectively match every held position state"), has an exit whose only condition is holding a position, like position_size 0 ("exit predicate fires in profitable, neutral, and losing states"), has an entry that always matches, a rule that can never match, or a rule that earlier rules make unreachable, has entry and exit rules that would trade back and forth on unchanged prices, has an entry size below 0 or above risk.max_position. The fix for the exit errors is to give every exit a real condition: a price level, a time before close, or an edge value. The weather example on the Examples page shows a rejected first draft and its fix. What the decision log shows When a rule matches, the Bot records that it fired before it acts. A fired buy_yes or buy_no can still place nothing, because entries are skipped while an order is resting or buying power is short. "Order placed" means Polymarket US accepted the order, not that it filled. If no rule matches, the log shows "no rule condition met". A refused order (a failed pre order check or a deployment risk limit) shows as a loop error with the reason. Built in strategies record only orders, errors and limit checks. Why a built in didn't trade (spread below spread_floor, no price yet, an order already resting) appears only in the Bot's log text. See Monitoring. Edge data on Polymarket US Custom Polymarket US strategies can read outside data. Built in strategies ignore it. The Edge Data pages list every field; the providers are: Provider Selector Default refresh Minimum refresh Units to know coinbase symbol, e.g. BTC USD 5s 1s, or 5s if you list any candle or indicator field change_ fields are fractions: 0.003 = +0.3%. nws station, e.g. KLGA (4 uppercase letters) 5m 60s Humidity and precipitation probabilities are fractions: 0.70 = 70%. economic_calendar event: FOMC, CPI or FOMC,CPI (no space) 15m 5m seconds_to_next and seconds_since_previous are seconds. Rules may read only fields listed in the alias's fields. refresh is a duration like 30s, 5m or 1h30m (there is no d unit here). A field can be temporarily unavailable, for example when a Coinbase candle is late. Every comparison with an unavailable value is false, including !=, and that holds on either side of a value_field comparison. Missing or stale data blocks entries If any declared alias has no data, or data older than 3 × its refresh, the Bot blocks new entries for that loop and records an "edge_data blocked" decision. Every field of the missing alias reads as unavailable, so conditions on it are false. The rules still run: a buy_yes or buy_no rule that matches is skipped, and a sell_all or cancel_all rule whose conditions read only market data works as usual. Resting orders are left in place, and the Bot tries the feed again on the next loop. An exit whose own conditions read the missing alias can't fire while it is down, so keep a price based sell_all exit that doesn't depend on edge data.2d:Tde2,Polymarket US Example Strategies This page collects complete platform: polymarket_us strategies: four custom strategies (NWS weather, shown as a rejected first draft and its fix; Coinbase MACD momentum; the FOMC calendar; and a dip buyer with no outside data) and three built ins. For what each key means, see All Polymarket US parameters; for how rules and built ins behave on Polymarket US, see Polymarket US Strategies and Edge Data. Every complete example below passes the same checks as a Studio save. Slugs are placeholders: use the exact slug of the market you mean to trade. The values are illustrative, not recommendations, and they keep sizes at 1 contract so exits fit the Max contracts per order Studio pre fills for them (1). Weather: NO on a cool NWS forecast A common first draft uses a single exit that sells whenever you hold anything. Studio rejects it, because that exit fires whether the trade is winning, flat or losing: The corrected version gives each exit a price condition. This strategy holds NO, so one exit fires when YES falls below 0.15 and a stop fires when YES rises above 0.75. The entry only fires while YES is between 0.30 and 0.60, so a fill is never stopped out on the next loop. It also cancels an unfilled entry if the forecast turns against the idea: If the NWS feed goes stale, entries are blocked until it returns, while take_profit and stop_loss, which read only price and position_size, keep running. cancel_if_forecast_turns reads the forecast, so it can't fire meanwhile. See Missing or stale data blocks entries. Crypto: Coinbase MACD momentum Buys one YES when BTC's 1 minute MACD is above its signal line and BTC is up more than 0.3% over 15 minutes. It exits on a price target, when MACD falls back below its signal (a value_field comparison), or 2 hours before close. MACD fields are candle fields, so refresh must be at least 5s. The time_to_expiry "1d" entry condition also keeps the Bot out of markets that report no end date, where time_to_expiry reads 0. Economic calendar: flat before the FOMC statement Enters one YES between 48 hours and 1 hour before the next FOMC statement and sells 45 minutes before it. A late unfilled entry is cancelled, and a skip guard blocks entries when buying power is low or the spread is wide. balance reads 0 when your balance can't be read, so the guard also blocks entries in that case. Dip buyer with a spread and volume guard No outside data: exits sit at the top, a skip rule blocks entries when the book is wide or thin, and a 1 contract YES entry fires in a 25–35¢ band. Because the guard sits below the exits, exits still run when the spread is wide. Built in: one level spread_capture When the book is at least 4¢ wide, rests one 1 contract YES bid and one 1 contract YES offer 2¢ either side of the midpoint, maker only, replaced every loop. With a 0.45 / 0.55 book this quotes 0.48 / 0.52. With a 0.48 / 0.51 book (3¢, below the floor) it cancels its quotes and places nothing. Built in: mean_reversion bands Buys YES at or below 20¢, buys NO when YES is at or above 80¢, and market sells when YES comes back within 2¢ of 50¢. Built in: bullish pre_announcement_drift One YES entry in the 6 hours before the market closes, then a market sell of that YES when the final 30 minute blackout begins. max_position: 1 keeps the entry and its exit within the deployment risk limits Studio pre fills (1 contract per order). See pre_announcement_drift. Before you deploy any of these, read Risk & Limits and plan how you'll watch the Bot in Monitoring.2e:T3888,Built in Strategies A built in strategy is a ready made trading template. You pick one with strategy: and tune it with a flat params: map. You don't write rules. Studio's AI writes this YAML for you; this section explains every setting it can use, so you can read the result, check it, and change it with confidence. This page covers what all five strategies share: how they run, their order sizes, the rules for writing params, how they differ from custom, backtests and Deep Research ranges. Each strategy has its own page for its parameters, and the risk, loop and other blocks they combine with have a page of their own. All six pages are listed under In this section. There are five built in strategies: Strategy In one line spread_capture Quote a YES bid and a YES ask around the mid when the spread is wide enough. mean_reversion Buy YES when YES is cheap or NO when YES is expensive, then exit near a target price. panic_fade Buy YES after a sharp drop from the recent 5 minute high, then exit on a small recovery. observation_momentum Buy in the direction of a recent price move, with a size that grows while the move continues. pre_announcement_drift Enter once in a window before the market closes, and optionally exit just before close. The sixth strategy: value, custom, replaces params with your own rules. See How custom differs. Note: Turbine is not a financial advisor. Every number in this section is an illustrative example of how a setting behaves, not a suggested threshold, size, or market. Nothing here implies that a strategy will make money. Backtest and paper trade before you deploy, and start small. See Risk & Limits. In this section Built in Strategy Risk, Loop and Other Blocks: How risk and loop apply to built in strategies, Kalshi's entry and portfolio caps and runtime checks, deployment risk limits, why a Kalshi Bot didn't trade, and which other blocks, such as trading_schedule, each venue accepts. spread_capture: How the quote ladder works, its parameters, venue differences, backtests and an example. mean_reversion: Entry bands, the exit target band and cooldown, venue differences, backtests and examples. panic_fade: How it fades sharp drops, its parameters, one fade at a time, venue differences, backtests and examples. observation_momentum: The momentum signal, the sizing staircase, its parameters, venue differences, backtests and an example. On Polymarket and Polymarket US it sells on a reversal; on Kalshi it has no exit. pre_announcement_drift: The entry window, blackout and release exit, its parameters, venue differences, backtests and examples. How built in strategies run Every loop.interval seconds the Bot finds its market or markets and runs the strategy's fixed logic once per market. Every threshold is a YES price in dollars, from 0 to 1. 0.08 means 8 cents. This includes the thresholds that trigger NO buys: entry_high: 0.85 means "buy NO when YES is at 0.85 or higher". Spreads, drops, gains and moves are worked out by subtracting prices, and the result can land a hair off the exact value. So a value exactly equal to a threshold may not count. A value one cent past the threshold always counts. For example, with recovery_exit: 0.05 a fade bought at 0.39 did not exit at 0.44, and did exit at 0.45. The template decides a few things for you. They are not configurable: panic_fade always looks back over a 5 minute window. mean_reversion always exits inside a band of ±0.02 around its target. Order sizes follow fixed formulas, shown in Order sizes. The price the strategy reads, and the order types it sends, depend on the venue: Venue Price the strategy reads Entries Exits Kalshi Last trade YES price, or the order book mid if nothing has traded. observation_momentum reads the last N trades instead. Limit order at the current price Reduce only, immediate or cancel limit at the best bid of the side held Polymarket YES token book mid, then the ask, the bid, then the last trade Limit order at the bought token's book mid Limit order at the best bid Polymarket US Last trade price, then the current price, then the book mid Limit order at the current price Market order spread_capture quotes are resting limit orders on every venue. The other four strategies share these rules on every venue: An entry counts once the venue accepts it. A skipped order leaves the strategy as it was: no cooldown starts, no fade is recorded, the momentum streak doesn't grow and drift doesn't count as entered. The strategy signals again on a later loop. An unfilled entry is cancelled after two loops (at least 60 seconds). While it rests, the strategy places no other entry. A part that filled is kept and managed like any position. Exits sell the side that is held, for what was bought. On Kalshi the Bot works out its own position from its own fills in this deployment, never more than your account holds. On Polymarket and Polymarket US, panic_fade and pre_announcement_drift sell what their own entry bought, and mean_reversion and observation_momentum sell what the account holds in the market. No entries on top of a position the strategy isn't managing. If the account holds contracts in the market that the strategy didn't buy (a manual trade, another Bot's, or a position this Bot opened before a redeploy), it doesn't enter there until they're closed, and it never sells them. This applies to every strategy on Kalshi, and to panic_fade and pre_announcement_drift on Polymarket and Polymarket US. On those two venues mean_reversion and observation_momentum treat everything held in the market as their own position instead: they don't enter while it's held (momentum adds only up to max_position), and their exits sell it. Venue details: Kalshi, Polymarket, Polymarket US. For how a strategy document fits together, see the Strategy Reference overview. For how the price bounds, max_position and loop.interval affect each strategy, see How risk and loop apply. Order sizes There is no size parameter except fade_size. Sizes come from these formulas: Order Kalshi Polymarket Polymarket US spread_capture quote 1 contract The market's minimum order size (often 5 shares) 1 contract mean_reversion entry min(max_position, 10) The market minimum min(max_position, 10) mean_reversion exit Everything this Bot holds, on the side it holds Every YES and NO share held Your whole held position panic_fade entry fade_size fade_size, raised to the market minimum fade_size panic_fade exit The YES the fade bought The YES the fade bought The YES the fade bought observation_momentum entry 1, 2, 3 … or 1, 2, 4 …, each capped at max_position Same, raised to the market minimum and cut to what fits under max_position Same, cut to what fits under max_position observation_momentum exit None Everything held on the other side, when the move reverses Same as Polymarket pre_announcement_drift entry min(max_position, 5) min(max_position, 5), raised to the market minimum min(max_position, 5) pre_announcement_drift release exit What the entry bought, on its side Same Same On regular Polymarket an order below the market's minimum order size (often 5 shares) is raised to the minimum, but never past max_position: if the minimum doesn't fit, the entry is skipped and the Bot logs an entry_size blocked decision. panic_fade is the exception to the max_position check: a fade_size at or above the minimum is sent as is. params.position_size is not a setting. It saves without an error and does nothing. To make a mean_reversion or drift entry smaller, lower risk.max_position. Markets and memory Kalshi. One Bot can run several markets. With market.series_ticker and market.selection: all it trades every bracket of the current event, and it keeps separate memory and a separate max_position for each one. New entries only go to the series' current market. Exits and quote cancels keep running on older markets you still hold. Deployment risk limits such as Max open contracts and Max daily notional traded are also checked per market (daily notional per market per UTC day), so total exposure and volume grow with the number of brackets. Polymarket and Polymarket US. One Bot trades one market and keeps one memory. On a rolling Polymarket series (market.series_slug or market.recurring) the Bot moves to the next window automatically and starts it with fresh memory: price history, the fade count, the momentum samples, the drift entry and the cooldown all reset. Shares still held in the old window settle with it. On every venue, a strategy's memory (cooldown clocks, price windows, fade counts, streaks, entered flags) lives in the running Bot. A restart or redeploy clears it. On Kalshi a restart doesn't lose track of what the Bot holds, because its position comes from its own fills in the deployment: after a restart it still exits them. A redeploy or update starts a new deployment: the Bot doesn't manage positions the previous deployment bought, and doesn't enter that market while one is still open. Close those positions yourself. Note: On Polymarket US, every built in exit is a market order, split into orders that each fit Max contracts per order. In paper trading a market order fills against the whole visible book at once or is rejected; it never rests. The params block params is a flat map of the settings for your strategy. Each strategy's page, listed under In this section, lists every key it reads. A few rules apply to all of them: Only the listed keys are read. Any other key is ignored without a warning. Switching strategy does not translate your params, because each strategy reads different keys. Numbers must be plain numbers. entry_low: "0.15" or cooldown: "60" (quoted) is text and fails validation, required or optional. Whole number keys accept 3 or 3.0 and reject 2.5. Write booleans as bare true or false. "false" in quotes, no and off fail with must be true or false without quotes. Text options must be one of the listed values. position_scale takes linear or exponential, and drift_direction takes auto, bullish or bearish. They are case sensitive, so Exponential fails with must be one of linear, exponential. A key set to null ( ) counts as omitted. Optional keys fall back to their default; required keys fail validation. .nan and .inf are rejected in every key, with must be finite. The strategy name itself is not case sensitive: Mean_Reversion works. The error reads as if the key were missing, because a quoted number doesn't count as a number. A quoted boolean is rejected too. Before this check, "false" in quotes switched post only on: How custom differs With strategy: custom you write the logic yourself as rules: conditions over fields such as price, spread and position, with actions such as buy_yes and sell_all. params is ignored. Custom strategies can also use settings that built in strategies can't, such as active_window, risk.max_notional, risk.max_loss, derived values, edge data and exit targets attached to entry rules. Venue support differs for each. Built in strategies are quicker to set up and read no external data. Custom rules take more work to write but let you express entries, exits and sizes exactly. See Custom Rules and Edge Data. Backtests Strategy Kalshi spread_capture Yes (resting order replay) mean_reversion Yes panic_fade Yes observation_momentum Yes pre_announcement_drift Yes This section describes Kalshi historical backtests. The Kalshi backtest steps through historical bars: 1 minute candles, or order book samples every loop.interval seconds. trading_schedule is honored. Where the backtest and the live Bot differ: Behavior Live Bot Backtest cooldown omitted 60 seconds 0 seconds recovery_exit omitted 0.04 recovery_target, default 0.50 recovery_exit: 0 Exits once the price is back at the fade price Treated as omitted post_only omitted (spread_capture) Off Always post only Entry fills Limit order at the current price Taker fill at the next bar's ask Unfilled entry Cancelled after two loops Fills at the next bar, or not at all max_position for panic_fade, and observation_momentum on Kalshi Not a holdings cap Caps holdings on each side Deployment risk limits Enforced on Kalshi and Polymarket US Not simulated Set cooldown and recovery_exit explicitly, as unquoted numbers, so both runs use the same values. See Backtest and Backtest data. Each strategy's page has a backtests section with the details for that strategy: spread_capture, mean_reversion, panic_fade, observation_momentum and pre_announcement_drift. Typical research ranges Deep Research runs are Kalshi only. Unless a research plan proposes something else, Deep Research builds 100 variants around your own values. These are the ranges it explores by default, not recommended settings. Strategy Varied by default How the values are built Example spread_capture spread_floor, price_floor, price_ceiling Your value × 0.5, 1, 1.5, 2 and 3 spread_floor 0.02 → 0.01, 0.02, 0.03, 0.04, 0.06 mean_reversion entry_low, entry_high, price_floor 5 evenly spaced values around each band edge, kept inside 0.01 to 0.99; price_ceiling stays fixed 0.15 and 0.85 → lows 0.01, 0.08, 0.15, 0.22, 0.29 and highs 0.71, 0.78, 0.85, 0.92, 0.99 panic_fade panic_threshold, price_floor, price_ceiling Your value × 0.5, 1, 1.5, 2 and 3 0.08 → 0.04, 0.08, 0.12, 0.16, 0.24 observation_momentum momentum_threshold, price_floor, price_ceiling Your value × 0.5, 1, 1.5, 2 and 3 0.03 → 0.015, 0.03, 0.045, 0.06, 0.09 pre_announcement_drift entry_hours_before, blackout_minutes_before, price_floor Whole numbers, 2 steps either side of your value; each step is a quarter of your value, rounded down, at least 1 6 → 4 to 8; 15 → 9, 12, 15, 18, 21 price_floor takes 4 values and price_ceiling 5, spaced around your own values: a floor of 0.05 becomes 0.01, 0.03, 0.05, 0.07 and a ceiling of 0.95 becomes 0.91, 0.93, 0.95, 0.97, 0.99. If your values leave no room for these grids, Deep Research falls back to fewer axes. For mean_reversion and pre_announcement_drift it first varies just one signal param (entry_low or entry_hours_before) with both price bounds. As a last resort it varies only the price bounds, on a fixed grid of 10 floors from 0.05 to 0.45 and 10 ceilings from 0.55 to 0.95, not built around your values. Sizing and timing params (order_count, fade_size, cooldown, lookback_periods) stay fixed by default. A proposed research plan can vary any numeric params key that is written in your strategy, so write out an optional param if you want it included.2f:T3272,Built in Strategy Risk, Loop and Other Blocks This page covers the settings outside params that shape how a built in strategy trades on Kalshi, Polymarket and Polymarket US: how risk and loop apply, Kalshi's entry and portfolio caps and runtime checks, deployment risk limits, why a Kalshi Bot didn't trade, and which other strategy blocks you can combine with a built in strategy. For each strategy's own params, and the order sizes they produce, start from Built in Strategies. How risk and loop apply Built in strategies use the same risk and loop keys as every strategy, but each one reads them in its own way. Setting Type Allowed values What it does for built in strategies risk.max_position whole number ≥ 1 (2.9 is rejected; 2.0 is fine) Sets or caps order size (see Order sizes). spread_capture stops quoting at it. observation_momentum stops buying at it on Polymarket and Polymarket US. It is not a cap on total holdings for panic_fade, or for observation_momentum on Kalshi. risk.price_floor number 0 to under 1, below price_ceiling New entries need a price strictly above it. panic_fade also exits when the price falls below it. spread_capture raises its buy quotes to at least the floor. risk.price_ceiling number above 0 up to 1 New entries need a price strictly below it. spread_capture lowers its sell quotes to at most the ceiling. loop.interval whole seconds ≥ 10, whole numbers only How often the logic runs. It also sets how many samples fit in panic_fade's 5 minute window and how precisely drift detects its blackout. risk.max_entries_per_market whole number ≥ 0; Kalshi only. Fractions such as 0.5 are rejected. Caps buy orders per market. Not recommended with spread_capture. risk.max_portfolio_positions whole number ≥ 0; Kalshi only. Fractions such as 0.9 are rejected. Refuses a buy in a new market once this many markets are active. 0 or omitted means no limit. risk.max_notional, risk.max_loss — Rejected Available only to custom strategies. The price bounds gate entries only. They never close a position, except for the panic_fade stop below the floor. On regular Polymarket a buy's price is also clamped between the floor and the ceiling. Sells aren't clamped, so the panic_fade stop sells at the bid, below the floor. risk.max_entries_per_market on Kalshi This counts buy orders, not contracts, per market. A buy counts while it rests and once any part of it fills; a buy cancelled with nothing filled frees its slot. Sells never count. The count comes from your Kalshi order history for this deployment, so it survives restarts. A redeploy starts a new count. 0 or omitted means no cap. When the cap is reached, further buys are skipped rather than refused. The Bot logs "entry skipped: max entries per market reached", and the strategy doesn't advance: mean_reversion's cooldown doesn't start, panic_fade records no fade, observation_momentum's streak doesn't grow, and pre_announcement_drift isn't marked as entered. Exits are never limited, and they only ever sell what the Bot holds. Warning: Combining risk.max_entries_per_market with spread_capture is not recommended. Once fills have used the allowance it posts only YES sell quotes, and on Kalshi a YES sell while you hold no YES is a NO buy that the cap doesn't limit. risk.max_portfolio_positions on Kalshi Before every buy, the Bot counts the active markets: markets where your account holds a position (from any Bot or a manual trade) plus markets where this Bot has resting orders. A buy in a market that isn't already active is refused once that count reaches the cap. The cap never limits sells, or buys in a market that is already active. The buy is refused, not skipped: the loop logs an error and the strategy doesn't advance its state, so it tries again on a later loop. On spread_capture the ladder stops at its first buy quote in a new market, after that loop's old quotes were cancelled, so no quotes are posted. Deployment risk limits Kalshi and Polymarket US Bots also enforce the deployment risk limits you confirm under Risk limits in the deploy dialog. Studio pre fills them from your strategy: Deployment risk limit Studio pre fills If a deployment sets no value Max contracts per order The strategy's largest order: min(max_position, 10) for mean_reversion, max_position for observation_momentum, min(max_position, 5) for pre_announcement_drift, fade_size for panic_fade, 1 for spread_capture 1 Max open contracts (held plus every resting order in the market) risk.max_position. The Bot applies the lower of this and max_position. The smaller of max_position and 3 Max dollars per order The same number as Max contracts per order, in dollars $10 Max daily loss (Kalshi only) risk.max_position, in dollars Off Max daily notional traded (your daily trading volume) The largest of the order size, max_position and 10 × the order size, in dollars $100 Circuit breaker (API error limit and Error window minutes) Not taken from the strategy 3 errors in 5 minutes An order larger than a limit is refused, not shrunk. The Bot logs an error and tries again on a later loop. The exception is a built in exit on Kalshi or Polymarket US, which is split into orders that fit Max contracts per order. The pre filled per order limits fit each strategy's own orders; lower them and larger orders are refused. Buys are also refused once held plus resting contracts in the market would pass the lower of max_position and Max open contracts, which can stop: observation_momentum streaks on Kalshi, once their growing orders add up past it, panic_fade fades when fade_size is above max_position, spread_capture ladders, because every resting quote counts (see order_count). Change the limits in the deploy dialog if your params produce larger sizes. Regular Polymarket built in Bots don't apply deployment risk limits, so on Polymarket max_position and the strategy's own sizing are your only size controls. See also Kalshi deployment risk limits and the overview. Note: Max daily notional traded is a cap on trading volume, reset at 00:00 UTC, and the venues count it differently. On Kalshi it counts each market separately: every buy and sell in that market since 00:00 UTC, including trades this Bot didn't make, and it's checked on buys. A series that opens a new market every 15 minutes starts each one at $0, so the limit rarely binds there. On Polymarket US it counts your whole account's trades since 00:00 UTC and is checked on every order except a sell that only reduces your position. The Circuit breaker pairs the API error limit with its window: with 3 and 5, three exchange errors within 5 minutes pause new orders for 5 minutes, then the Bot resumes on its own. An error is a request to the exchange that fails or gets no answer within 15 seconds; on Kalshi, a read that can't connect is tried up to 3 times before it counts, and a rate limit reply never counts. Note: Max daily loss is enforced on Kalshi only: once the deployment's P&L since 00:00 UTC, realized plus unrealized, reaches it, buys are refused until 00:00 UTC while exits keep running. Polymarket US Bots don't read it, and the deploy dialog doesn't show it there. Once the API error limit trips, the Bot refuses new orders for one error window, then resumes on its own. During it a Polymarket US sell that reduces your position still goes out, while Kalshi built in exits, which aren't reduce only, wait out the window. Kalshi runtime checks Kalshi Bots run a few fixed checks before every order. You can't change them, and they also apply in paper trading. Fresh trades. An order is refused when the market's most recent trade, by anyone, is more than 120 seconds old. A market that has never traded passes. The market must also be open, and a buy needs a two sided book. On quiet markets spread_capture cancels its quotes and posts none, and the other strategies wait until a fresh trade prints. Order budget. One Bot sends at most 20 orders per rolling 60 seconds, shared across all its markets. Cancels don't count. Orders beyond that are skipped, not refused. Rate limit backoff. Each Bot shares a request budget across its own threads, replenished at 8 requests per second with a burst of 8, and a rate limited read is tried again after a short wait. When Kalshi still refuses, orders are skipped for the wait Kalshi asks for or, if it doesn't say, for 2 seconds, doubling while refusals continue up to 30 seconds. Rate limit errors never count toward the API error limit. A skipped entry leaves the strategy's state unchanged, as described under risk.max_entries_per_market, and a skipped exit is sent again on a later loop while the position is still held. A refused order raises an error instead, and the strategy tries again on a later loop. Regular Polymarket and Polymarket US don't run the fresh trade check or the order budget. Polymarket US refuses every order unless the market is active, and a buy also needs both a bid and an ask; an exit only needs a bid. Buys also need enough buying power. A refused exit is retried on a later loop. See Built in strategies on Polymarket US. Why a Kalshi Bot didn't trade Kalshi mean_reversion and panic_fade Bots record a reason on each loop where they don't trade. The other built in strategies only log their waits and errors. See Monitoring. Message Meaning no trades yet, waiting No price yet: nothing has traded and the book isn't two sided. price within neutral band — waiting mean_reversion: the price is between entry_low and entry_high, or outside the price bounds. holding, waiting for exit_target mean_reversion: the Bot holds a position and the price isn't within 0.02 of exit_target. entry resting, waiting for fill mean_reversion: the Bot's entry is resting unfilled. It is cancelled after two loops. entry cooldown active mean_reversion: you're flat, but the cooldown hasn't passed or this isn't the series' current market. holding fade, waiting for recovery panic_fade: a fade is open, the price hasn't risen by recovery_exit and is still above price_floor. fade buy resting, waiting for fill panic_fade: the fade's buy hasn't filled yet. It is cancelled after two loops. drop below panic_threshold (or fade budget spent) panic_fade: the drop is too small, max_fades is used up, the price is outside the bounds, or this isn't the series' current market. entry skipped: max entries per market reached Any strategy: risk.max_entries_per_market is used up in this market. order attempt budget exhausted or Kalshi rate limit backoff active A runtime check skipped the order (see Kalshi runtime checks). Combining with other blocks Built in strategies accept fewer blocks than custom. Some are rejected, and some are accepted but never used. Block or key Kalshi Polymarket Polymarket US trading_schedule Supported Rejected Rejected active_window Rejected (custom only) Rejected Rejected rules Accepted, ignored Accepted, ignored Rejected edge Accepted, ignored Rejected Accepted, ignored derived Rejected Rejected Rejected risk.max_entries_per_market Supported Rejected (custom only) Rejected risk.max_portfolio_positions Supported Rejected Rejected risk.max_notional, risk.max_loss Rejected (custom only) Rejected Rejected market.selection Supported with series_ticker Not available Not available market.min_order_size Rejected Fallback for markets pinned by token IDs Rejected "Accepted, ignored" means the strategy saves but the Bot never reads that block. Built in strategies read no external data, so an edge block has no effect on them. Ignored rules are still partly checked: an unknown rule key, a rule level trading_schedule, or entry_profit_offset, entry_stop_loss_offset and entry_profit_targets are rejected. On regular Polymarket, market.min_order_size only matters for a market pinned by yes_token_id and no_token_id. It sets the spread_capture quote size and the smallest order the other built ins send, and defaults to 5. For any other selector the Bot uses the market's own minimum. The value isn't checked when you save, and a non numeric value stops the Bot from starting. A token pinned market has no known end date, so pre_announcement_drift never enters on one. See market.min_order_size. trading_schedule on Kalshi On Kalshi, a trading_schedule works with every built in strategy. The schedule syntax is under Trading schedule in the Kalshi reference. With a built in strategy it does this: Buy orders outside the allowed hours are refused and logged. The signal is checked again on later loops. When the schedule closes, and once at startup, the Bot cancels its own resting entry orders. Exits keep running. Every sell is reduce only and capped at what this Bot owns on the side it sells, so YES and NO positions both exit. A sell with nothing to sell is refused. Warning: spread_capture with a trading_schedule is not recommended. While you hold no YES, each loop posts one buy quote, then stops with an error on its first sell quote.30:T14ae,spread_capture This page covers spread_capture, one of the five built in strategies, on Kalshi, Polymarket and Polymarket US: how it quotes, each parameter, venue differences, backtests and an example. Rules all five share, such as order sizes and how to write params, are on the Built in Strategies page. Every number here is an illustrative example, not a suggested setting. spread_capture quotes both sides of a market around the mid. Each loop, for each market: 1. If your position is already at risk.max_position or more, it skips quoting. Quotes already resting stay where they are. 2. It reads the best YES bid and YES ask. On Kalshi the ask is 1 minus the best NO bid. 3. If the book is one sided, or the ask minus the bid is less than spread_floor, it cancels its open quotes and posts none. 4. Otherwise it cancels its open quotes and posts order_count levels. Level i buys YES at mid − i × spread_floor/2 and sells YES at mid + i × spread_floor/2. Note: Each refresh cancels only the Bot's own quotes. Your manual orders and other Bots' orders in the market stay resting. On Kalshi and Polymarket US they still count toward Max open contracts. How the Bot knows which orders are its own: Kalshi: the Bot recognizes its orders by this deployment's client order id. When you redeploy a Bot in place, the deploy asks you to adopt the market's resting orders; the previous deployment's quotes you adopt are refreshed like the new ones, so its old ladder doesn't sit at stale prices. An adopted manual order is still never cancelled. Polymarket and Polymarket US: orders carry no client id, so the Bot remembers the id of every order the exchange accepts from it. That memory survives restarts and redeploys, but not stopping the Bot, so quotes a stopped Bot left behind stay resting until you cancel them. Parameter Type Default Allowed values What it does spread_floor number (YES dollars) Required 0 Minimum spread before the Bot quotes. Also the quote spacing: each level sits spread_floor/2 further from the mid. order_count whole number Required ≥ 1 Quote levels on each side. post_only boolean false true, false Maker only quotes: a quote that would trade immediately is rejected instead. refresh_on_fill boolean false true, false No effect. The ladder is cancelled and re posted every loop anyway. spread_floor Quotes are centered on the mid, not on the edge of the book. When the spread is wider than spread_floor, the first level sits inside the current spread. Prices are rounded to whole cents on Kalshi, to the market's tick on Polymarket (buys round down, sells round up), and to 2 decimals on Polymarket US. A buy quote below price_floor is raised to the floor, and a sell quote above price_ceiling is lowered to the ceiling. If the floor sits above the ask, the raised buy can trade immediately unless post_only: true. order_count Each level is one YES buy and one YES sell. Orders go out one at a time. On Kalshi and Polymarket US, a quote refused by a deployment risk limit ends that loop's ladder. The open contract cap, the lower of max_position and Max open contracts, counts every resting quote, so at 3 a Kalshi or Polymarket US ladder stops after about 2 levels. Raise both max_position and Max open contracts to about 2 × order_count. On Kalshi the ladder sends up to 2 × order_count orders per market per loop, and the order budget is 20 per 60 seconds. With loop.interval: 10 and order_count: 3 that is 36 orders a minute, so some loops post no quotes. On regular Polymarket each buy quote is the market's minimum size (often 5 shares), whatever max_position is, so a fill can take you past max_position. spread_capture by venue Kalshi Polymarket Polymarket US Quote size 1 contract Market minimum (often 5 shares) 1 contract Sell quote while you hold no YES Posted. A fill opens NO, because selling YES you don't hold is a NO buy. Not posted. Sells only sell YES you hold. Posted Orders cancelled each loop The Bot's own quotes, plus a previous deployment's quotes you adopted when redeploying The Bot's own orders The Bot's own orders Deployment risk limits Enforced Not applied Enforced On Kalshi, YES sell quotes are never blocked by risk.max_entries_per_market or by the Max open contracts check, because both apply only to buys. Resting sell quotes still count toward the open contracts total that the next buy is checked against. spread_capture backtests Kalshi spread_capture backtests use a resting order replay, which differs from live in a few ways: Quotes are always post only. Each level is modelled as a 1 contract YES bid and a 1 contract NO bid, and max_position caps YES and NO holdings separately. When the mid is outside price_floor to price_ceiling, the backtest skips quoting; the live Bot clamps its prices instead. See Backtest for more about Kalshi historical testing. spread_capture example Illustrative only: a one level ladder on a single Kalshi game market. It quotes only when the spread is about 4 cents or more (an exactly 4 cent spread can miss by rounding), and stops refreshing once 3 contracts are held. With a mid of 0.50 it posts a buy at 0.48 and a sell at 0.52. The one level ladder fits the deployment risk limits Studio pre fills. The ticker is an example; saving a strategy doesn't check that the market exists.31:T135b,mean_reversion This page covers mean_reversion, one of the five built in strategies, on Kalshi, Polymarket and Polymarket US: its entry bands, exit target and cooldown, venue differences, backtests and examples. Rules all five share, such as order sizes and how to write params, are on the Built in Strategies page. Every number here is an illustrative example, not a suggested setting. mean_reversion buys when the price is at an extreme and exits when it comes back toward a target. Each loop, for each market: 1. It reads the YES price. 2. If it is flat, no entry is resting, the cooldown has passed and (on Kalshi) this is the series' current market: if price_floor Parameter Type Default Allowed values What it does entry_low number (YES price) Required Below entry_high Buy YES when YES is at or below this price. entry_high number (YES price) Required Above entry_low Buy NO when YES is at or above this price. exit_target number (YES price) 0.5 0 to 1 Exit when YES comes within 0.02 of this price. cooldown whole seconds 60 ≥ 0 Minimum time between entry orders. position_size — — — Ignored. Entry size comes from risk.max_position (see Order sizes). entry_low and entry_high Validation only checks that entry_low is below entry_high. Two things are worth checking yourself: entry_low must be above price_floor, or YES entries can never happen (the floor test is strict). Setting entry_high at or above price_ceiling switches off NO entries. The entry is a limit order at the current price. While it rests the Bot places no other entry. If it hasn't filled after two loops (at least 60 seconds), the Bot cancels it and, once the cooldown has passed, enters again at the new price. A part that filled is kept and exits like any position. A trading_schedule that closes on Kalshi also cancels a resting entry. On Polymarket and Polymarket US any order resting in the market, including one you placed, also holds entries back. Both sides exit the same way: a YES position sells YES and a NO position sells NO. exit_target The exit is a narrow band, not a threshold. It fires only when the YES price is strictly within 0.02 of exit_target. At whole cent prices, a target of 0.50 exits at 0.49, 0.50 or 0.51. If the price jumps past the band between loops, you keep holding, possibly to settlement. There is no stop loss. On Kalshi the exit sells everything this Bot holds; on Polymarket US it sells the whole position on the side you hold, as market orders. On both, it is split into orders no larger than Max contracts per order, which Studio pre fills at the entry size, min(max_position, 10). cooldown The cooldown is measured from the last entry the venue accepted, not from a fill or an exit. A skipped entry (a resting order, a Kalshi runtime skip, or not enough buying power on Polymarket US) doesn't start it. On Kalshi each market has its own clock. On Polymarket and Polymarket US there is one clock per Bot, and each new window of a rolling Polymarket series starts without one. The cooldown only spaces entries; it never delays an exit. Write it as an unquoted whole number of seconds. 2.5, "60" and "5m" fail with params.cooldown: must be an integer, and 1 fails with must be = 0. Backtests use 0 seconds when cooldown is omitted, so set it explicitly if you want the backtest to match the live Bot. mean_reversion by venue Kalshi Polymarket Polymarket US Entry size min(max_position, 10) The market minimum. With max_position below it, entries are skipped. min(max_position, 10), after a buying power check Unfilled entry Cancelled after two loops; a new entry follows after the cooldown Same Same Exit Sells the side this Bot holds, for everything it holds, at that side's best bid Sells every YES and NO share you hold at the best bid Market sell of the side and size you hold Cooldown clock Per market Per market window One per Bot mean_reversion backtests The backtest runs the same entry and exit tests on each historical bar, then fills the order as a taker at the next bar's ask. The live Bot posts a limit order at the current price instead. Entry size is min(max_position, 10) on Kalshi, the exit closes both sides, and the default cooldown is 0 seconds (60 live). mean_reversion examples Illustrative only: YES only reversion on the most liquid market of the current Kalshi 15 minute BTC event, with new entries only on weekdays from 09:30 to 16:00 New York time. It buys 2 contracts when YES is above 0.05 and at or below 0.15, and exits when YES trades at 0.49 to 0.51. Studio pre fills Max contracts per order at 2, min(max_position, 10), so the entry and the one order exit fit. Illustrative only: both sides on the rolling Polymarket BTC 15 minute Up/Down series. It buys Up when Up is at or below 0.30, buys Down when Up is at or above 0.70, and sells everything when Up is within 0.02 of 0.50. Entries are the market minimum, so 5 shares on a market whose minimum is 5. Each window starts with a fresh cooldown.32:T13ae,panic_fade This page covers panic_fade, one of the five built in strategies, on Kalshi, Polymarket and Polymarket US: how it fades sharp drops, each parameter, one fade at a time, venue differences, backtests and examples. Rules all five share, such as order sizes and how to write params, are on the Built in Strategies page. Every number here is an illustrative example, not a suggested setting. panic_fade buys YES after a sharp drop and sells on a small recovery. It only fades drops; it never sells into spikes. Each loop, for each market: 1. It records the YES price and keeps the last 5 minutes of its own samples. 2. It computes the drop: the highest price in the window minus the current price. 3. It buys fade_size YES at the current price when all of these hold: the drop is at least panic_threshold; fewer than max_fades fades have been used; price_floor Parameter Type Default Allowed values What it does panic_threshold number (YES dollars) Required 0 Drop from the 5 minute high that triggers a buy. fade_size whole number Required ≥ 1 YES contracts bought per fade. The exit sells what the fade bought. recovery_exit number (YES dollars) 0.04 0 to 1 Take profit distance above the fade's entry price. Set it explicitly: backtests use a different default. max_fades whole number 3 ≥ 0; 0 disables entries Most fades that fill. recovery_target number — — Ignored by live Bots. Backtests use it (default 0.50) only when recovery_exit is missing or 0. panic_threshold The window is built from the Bot's own loop samples, so loop.interval must be well under 300 seconds. At 30 seconds the window holds about 10 samples. At 300 seconds or more it holds one, and the strategy never fires. The window starts empty after a restart. On a rolling Polymarket series the window starts empty in each new market, so one market's closing price is never compared with the next one's. fade_size fade_size alone sets the size of each fade. On Kalshi and Polymarket US, Studio pre fills Max contracts per order from fade_size, but a fade is refused once held plus resting contracts would pass the lower of max_position and Max open contracts (see Deployment risk limits), so keep fade_size at or below max_position. On regular Polymarket a fade_size below the market's minimum order size (often 5 shares) is raised to the minimum, as long as max_position is at least the minimum; otherwise the fade is skipped. If a fade's buy only partly fills, the exit sells the part that filled and cancels the rest. max_fades Kalshi: counted per market when the fade's buy fills, so each new market in a series starts at 0. Polymarket: counted when a fade fills, per market, so each window of a rolling series starts at 0 (see Markets and memory). Polymarket US: one counter for the Bot's whole life, counted when a fade fills. Every counter resets when the Bot restarts. One fade at a time On every venue a fade must be sold, or its unfilled buy cancelled, before the next one can start. The 5 minute high stays in the window, so a new fade can follow soon after an exit if the price is still down. On Kalshi a restart doesn't lose an open fade: the Bot still holds its YES, and measures the recovery from the first price it sees after the restart. On Polymarket and Polymarket US a restart forgets the fade, so the Bot won't exit YES it bought before the restart. panic_fade by venue Kalshi Polymarket Polymarket US Fades open at once 1 per market 1 1 max_fades counter Per market Per market window One per Bot Exit order Reduce only, immediate or cancel sell of the fade's YES at the YES bid Limit sell of the fade's YES at the YES bid Market sell of the fade's YES Stop below price_floor Sells at the YES bid Sells at the YES bid Market sell Minimum order size None fade_size raised to the market minimum (often 5 shares) None Deployment risk limits Enforced Not applied Enforced panic_fade backtests The backtest uses a 5 minute window of historical bar prices and buys at the next bar's ask. Like the live Bot it opens one fade at a time and counts a fade only when it fills. Unlike the live Bot it caps holdings at max_position and sells the whole position on exit. When recovery_exit is omitted, the backtest exits at the hidden recovery_target distance (0.50 by default) while the live Bot exits at 0.04. The backtest also treats recovery_exit: 0 as omitted, while a live Bot with 0 exits as soon as the price is back at the fade price. Always set recovery_exit to a number above 0. panic_fade examples Illustrative only: 1 contract fades on the most liquid strike of the current Kalshi BTC daily event. It buys after a 12 cent drop, sells at +6 cents or below 0.15, makes at most 2 fades per market, and places no new entries on weekdays from 08:25 to 08:45 New York time. A fade's buy that hasn't filled after two loops is cancelled, and so is one still resting when a blackout starts. Illustrative only: a single 1 contract fade on one Polymarket US market. max_fades: 1 means one fade for the life of the Bot. The slug is an example.33:T13c9,observation_momentum This page covers observation_momentum, one of the five built in strategies, on Kalshi, Polymarket and Polymarket US: its momentum signal, the sizing staircase, each parameter, venue differences, backtests and an example. Rules all five share, such as order sizes and how to write params, are on the Built in Strategies page. Every number here is an illustrative example, not a suggested setting. observation_momentum buys in the direction of a recent price move. Each loop, for each market: 1. It compares the newest and oldest of the last lookback_periods prices. The difference is the move. 2. If the move is smaller than momentum_threshold either way, it resets its streak to 0 and does nothing. 3. Otherwise it buys YES on an up move or NO on a down move, provided price_floor Parameter Type Default Allowed values What it does lookback_periods whole number Required ≥ 2 How many recent prices to compare, newest against oldest. momentum_threshold number (YES dollars) Required 0 Smallest move, up or down, that counts as momentum. position_scale text linear linear, exponential How order size grows over consecutive signals. lookback_periods The same number means different time spans on different venues: Kalshi: the market's last N trades, fetched every loop. The trade timestamps set the window, not loop.interval. It needs at least 2 trades. Polymarket and Polymarket US: the Bot's own last N loop samples, one per loop.interval, so the window is about (N − 1) × loop.interval. It starts comparing as soon as 2 samples exist. The samples reset on restart and at each new window of a rolling Polymarket series. lookback_periods never controls order size. momentum_threshold The move is in absolute dollars, not a percentage. Kalshi prices move in whole cents, so a threshold of 0.01 or less fires on almost any change. On Kalshi, if no new trade prints, the last N trades don't change, so the move stays above the threshold and the Bot buys again on every loop with a growing size. It stops when a new trade moves the price back, or when the 120 second fresh trade check starts refusing orders. position_scale For the n th consecutive signal, counting from 0: linear: min(max_position, n + 1), so 1, 2, 3, … exponential: min(max_position, 2^n), so 1, 2, 4, 8, … An omitted key means linear. Any value other than linear or exponential, including Exponential, is rejected. There is no fixed size option; max_position: 1 is the only way to get 1 contract orders. The streak advances after an order is accepted and resets when the move drops below momentum_threshold, or after a reversal sale on Polymarket and Polymarket US. A refused or skipped order doesn't advance it. Studio pre fills Max contracts per order at max_position, the largest order the streak can reach (see Deployment risk limits). Warning: On Kalshi the strategy has no exit and keeps buying on every qualifying loop until the open contract cap, the lower of max_position and Max open contracts, refuses further buys. On Polymarket and Polymarket US it stops at max_position and sells on a reversal. observation_momentum by venue Kalshi Polymarket Polymarket US lookback_periods counts Trades Loop samples Loop samples Entry order Limit at the last trade price (NO: 1 − price) Limit at the bought token's book mid, at least the market minimum Limit at the current price (NO: 1 − price) Total holdings bounded by The lower of max_position and Max open contracts max_position The lower of max_position and Max open contracts Exit None Sells the held token at its bid when the move reverses Market sells of the held side when the move reverses, split to fit Max contracts per order On regular Polymarket every order is raised to the market's minimum order size (often 5 shares), so a streak starts at the minimum and grows only once the scale passes it. With max_position below the minimum, the strategy can't trade there and logs why. observation_momentum backtests The backtest reads trade prices only. It waits until N bars with a trade price have accumulated, then compares the latest close with the close N − 1 bars earlier. Sizes follow the same position_scale rule, holdings on each side are capped at max_position, and there is no reversal sale. Live on Kalshi, held plus resting contracts on both sides together are capped at the lower of max_position and Max open contracts. observation_momentum example Illustrative only: trade momentum on the most liquid bracket of the current Kalshi NYC high temperature event. When YES has moved about 4 cents or more over the last 5 trades it buys in that direction, sizing consecutive signals 1, 2, 3. max_portfolio_positions: 1 refuses a buy in a new market while your account already holds another. Studio pre fills Max contracts per order at 3 and Max dollars per order at $3, which covers the size 3 order at up to the 0.90 price ceiling ($2.70). Holding 1 + 2 + 3 would need max_position of at least 6: at 3, the size 3 order is refused once sizes 1 and 2 have filled. The strategy reads no weather data.34:T128a,pre_announcement_drift This page covers pre_announcement_drift, one of the five built in strategies, on Kalshi, Polymarket and Polymarket US: its entry window, blackout and release exit, each parameter, venue differences, backtests and examples. Rules all five share, such as order sizes and how to write params, are on the Built in Strategies page. Every number here is an illustrative example, not a suggested setting. pre_announcement_drift enters once in a window before the market closes. The market's close time stands in for the announcement; no economic calendar is used. Each loop, for each market: 1. It measures the time until the market closes (Kalshi close time, Polymarket end date, Polymarket US end or close time). 2. Entry window: hours to close ≤ entry_hours_before and minutes to close blackout_minutes_before. If it hasn't entered yet and price_floor Parameter Type Default Allowed values What it does entry_hours_before whole hours Required ≥ 1 When the entry window opens, in hours before close. blackout_minutes_before whole minutes Required ≥ 0 Final minutes before close with no entries. The release exit fires when it starts. 0 means no blackout. drift_direction text auto auto, bullish, bearish bullish buys YES, bearish buys NO. auto (or omitted) buys YES below 0.5 and NO at 0.5 or above. exit_on_release boolean false true, false Exit when the blackout begins. Otherwise the position is held to settlement. entry_hours_before Whole hours only; 1.5 is rejected. The Bot remembers that it entered per market on Kalshi and Polymarket (each window of a rolling series is a new market) and once per Bot on Polymarket US. On Kalshi a restart still sees the position the Bot entered. On Polymarket and Polymarket US the memory resets on restart, so a restart inside the entry window can enter again. If the market has no close time, Polymarket and Polymarket US Bots never enter, and a Kalshi Bot logs an error on every loop. The error says "requires positive entry_hours_before" for any value that isn't a positive whole number, including 1.5. blackout_minutes_before Keep loop.interval well below blackout_minutes_before × 60 seconds, or a loop may never land inside the blackout before the market closes. The two windows are not cross checked: if blackout_minutes_before is at least entry_hours_before × 60, the entry window is empty, and the strategy still saves. exit_on_release Despite the name, the exit fires at the start of the blackout, before the market closes. It sells what the entry bought, on the side it bought, whether that is YES or NO and whether the entry filled fully or partly: Kalshi: reduce only, immediate or cancel sells at that side's best bid, split to fit Max contracts per order. Regular Polymarket: a limit sell of that token at its best bid. Shares you held before the entry aren't sold. Polymarket US: market sells of that side, split to fit Max contracts per order. Backtests read this value more strictly than live Bots: an integer 1, or text such as yes, is off in a backtest and on in a live Bot. Write true or false. pre_announcement_drift by venue Kalshi Polymarket Polymarket US Close time Market close time Market end date End date, else close time No close time Error on every loop Never enters Never enters "Entered" memory Per market Per market window One per Bot Entry order Limit at the price (NO: 1 − price) Limit at the bought token's book mid, at least the market minimum Limit at the price (NO: 1 − price) Release exit Sells what the entry bought at that side's bid Limit sell of what the entry bought at its bid Market sell of what the entry bought pre_announcement_drift backtests Backtests use each historical market's close time and the same two windows on bar timestamps. Entry size is min(max_position, 5). With exit_on_release, the backtest sells both sides at the next bar once the blackout starts. pre_announcement_drift examples Illustrative only: one YES entry on the most liquid bracket of the next closing Kalshi Fed event, between 12 hours and 30 minutes before close, sold when the final 30 minutes begin. The release exit sells the YES the entry bought. Studio pre fills Max contracts per order at 2 and Max dollars per order at $2, which covers the entry at up to the 0.90 price ceiling ($1.80). A 120 second loop is far shorter than the 30 minute blackout. Illustrative only: one NO entry of 5 shares on a single regular Polymarket yes/no market, between 24 hours and 1 hour before its end date, with everything sold when the final hour begins. The release exit sells the NO the entry bought. The market must be a standalone yes/no market: multi outcome (negative risk) markets save but are refused when the Bot starts. The slug is an example.35:T2d14,Custom Rules A strategy: custom Bot is an ordered list of if then rules. On every loop tick the Bot reads a fresh snapshot of the market and your account, walks your rules from the top, and runs the action of the first rule whose conditions are all true. This section documents every key a rule can use, every field a condition can read, what each action does on each venue, and exactly what Studio rejects when you save. It is split into the pages listed under In this section. This page covers what every rule shares: the rule anatomy, the full rule keys table, and how rules are evaluated on each tick. Custom rules work on Kalshi, Polymarket and Polymarket US. The grammar is the same everywhere, but the available fields and the way orders are placed differ by venue, and each page in this section calls out the differences. Kalshi Perps and Arbitrage use the same when / field / op shape with their own fields and actions, and are documented on their own pages. Note: Every example in this section is illustrative. Market tickers, slugs, thresholds and sizes are small placeholder values chosen to show the syntax. They are not recommendations, and no rule set guarantees a result. Start small, backtest where you can, and read Risk & Limits before you deploy. In this section Custom Rule Conditions and Missing Data: The condition keys, all vs any, operators, value vs value_field, durations for time_to_expiry, and what happens when data is unavailable, a tick is skipped or a rule errors. Custom Rule Field Catalog: Every field a custom rule can read, with units, venue availability and backtest support, how each venue computes it, and the edge data and derived metric fields. Custom Rule Actions: Every custom rule action and exactly what it does on each venue and in backtests, plus how size and price bounds work. Custom Rule Validation: What Studio checks when you save a custom strategy: the three validation passes, the required exit rule, the behavior checks, and what the checker cannot see. Custom Rule Exit Checks: Exit rules the validator rejects (selling whenever you hold, no hold zone, exits that fire right after entry), each with a rejected strategy and a version that saves. Custom Rule Entry Checks: Entry and rule set problems the validator rejects (contradictions, always matching entries, unreachable rules and oversized entries), each with a rejected strategy and a version that saves. Custom Rule Example Strategies: Seven complete custom strategies that save as written: three for Kalshi, two for Polymarket and two for Polymarket US. Rule anatomy A rule has a name, a when block of conditions, and an action. This is a complete rule: Each condition compares a live field with an operator (op) against either a fixed value or another field (value_field); Conditions covers every condition key. A buy rule usually adds a size. Rule keys Parameter Type Default Allowed values What it does rules list of rules none 1 or more rules; required for strategy: custom The ordered rule list, checked top to bottom every tick. See How rules are evaluated. rules[].name text none (required) Any non empty text; use letters, digits, spaces, _ and A label for decision logs and validation errors. See name. rules[].when mapping none (required) Exactly one of all or any The rule's trigger. See all and any. rules[].when.all list of conditions none 1 or more conditions Matches when every condition is true. rules[].when.any list of conditions none 1 or more conditions Matches when at least one condition is true. rules[].action text none buy_yes, buy_no, sell_yes, sell_no, sell_all, cancel_all, skip What the rule does when it is the first match. Exactly one of action or orders. See Actions. rules[].size whole number 1 for buys Positive, at most risk.max_position Contracts (Kalshi, Polymarket US) or shares (Polymarket) to buy. See Size rules. rules[].orders list none Kalshi only Composite resting buy orders instead of action. See Advanced keys. rules[].max_combined_price number none Above 0, at most 1; Kalshi only Caps the combined price of a paired YES/NO composite quote. rules[].entry_execution text omitted (GTC) immediate_or_cancel; Kalshi custom buy_yes / buy_no only, without orders Recheck the entry before IOC submission; cancel any unfilled remainder. See Immediate entries. rules[].entry_profit_offset number (dollars) none Above 0, below 1; Kalshi only Per fill take profit on a sell_yes / sell_no rule. rules[].entry_stop_loss_offset number (dollars) none Above 0, below 1; Kalshi only Per fill stop loss on a sell_yes / sell_no rule. rules[].entry_profit_targets list of rows none Kalshi only Per fill take profit table keyed by entry price. rules[].entry_profit_min_time_to_expiry duration none Whole s, m or h, such as "2h"; Kalshi only Limits a profit table to fills made before a time to close cutoff. rules[].trading_schedule mapping none Kalshi buy_yes / buy_no rules only Weekly hours when this entry rule may buy. Any other key is rejected when you save, including conditions, id, description, price, order_type and side (for example unsupported custom rule key "conditions"). Conditions always live under when.all or when.any. rules only runs with strategy: custom. On Kalshi and Polymarket, a built in strategy saves a rules block but never runs it, and does not check its fields, operators or actions. An entry_execution setting is still rejected on a built in strategy. Polymarket US rejects it (Polymarket US built in strategies do not support top level rules). See Built in Strategies. name name is required and is only a label. It does not affect priority; the position of the rule in the list does. It appears in the decision log when the rule fires, and validation errors list rule names so you can find the problem. Keep names to letters, digits, spaces, underscores and hyphens, and make each one unique. Double quotes and backslashes in a name are not supported: a name such as take "profit" saves, but the Bot then fails to start. Duplicate or blank names save too, but they make the decision log ambiguous. Advanced keys (Kalshi only) Eight rule keys add Kalshi only behavior on top of the basic grammar: immediate entries (entry_execution), composite maker orders (orders, max_combined_price), per fill exits that manage each purchase at its own entry price (entry_profit_offset, entry_stop_loss_offset, entry_profit_targets, entry_profit_min_time_to_expiry), and a rule level trading_schedule for entries. Polymarket and Polymarket US custom strategies reject all eight. Composite orders, per fill exits and schedules are documented in Advanced Kalshi Rules. How rules are evaluated One tick, step by step Every tick, for each market the strategy trades: 1. The Bot reads a fresh snapshot: prices and the order book, your position, your resting orders, your balance, and any edge data or derived metrics you declared. 2. If a declared data source is unavailable, its fields read as unavailable and new entries are blocked for that market this tick; exits still run. See Missing or unavailable data. 3. Rules are checked in file order. Every condition of a rule is evaluated, then combined with all or any. 4. The first rule that matches runs its action, and evaluation stops for that market until the next tick. One matched rule, one action. The exception is a buy rule that matches while entries are blocked (see When entries are blocked): it is skipped and the rules below it still run. 5. If no rule matches, nothing is traded and the decision log records "no rule condition met". After the whole cycle finishes, the Bot waits loop.interval seconds (at least 10) and starts again. The interval is a pause between cycles, not a fixed clock. With a series or a multi market selection on Kalshi, each market gets its own snapshot and its own first match, and an error in one market does not stop the others. Rules are not evaluated at all while a Kalshi strategy is halted by risk.max_loss (the Bot instead cancels its orders and sells the position this run opened), or before an active_window starts (Kalshi and Polymarket). When the window ends, the Bot cancels its own resting buys once and blocks new entries, but keeps evaluating rules so exits still run; it never closes a position on its own. See When entries are blocked. skip is a real match: it places no order, but it still ends evaluation for the tick. A buy rule that matches and is then held back by a risk limit (for example risk.max_entries_per_market or risk.max_notional) also counts as the match for that tick. On Kalshi, the Studio live terminal records each tick as a decision tree: every rule and condition is shown with the recorded value, the threshold, and a status of Met, Not met, Not evaluated, Not recorded (the value was unavailable), Blocked or Error. A record covers at most 16 markets, 32 rules and 16 conditions per rule; anything beyond that is left out and the record is marked incomplete. On Polymarket and Polymarket US, the decision log shows which rule fired, or that no rule matched, but not the value of each condition. Rules have no memory Rules see only the current snapshot. There is no "I already entered" flag and no "price crossed above" event. Express that kind of state through the account: position_size == 0 to allow an entry only while flat, position_size 0 for exits. order_count == 0 to avoid stacking a second order on top of a resting one. risk.max_entries_per_market to cap how many entries a market can get (Kalshi and Polymarket; Polymarket US rejects it). On a regular Polymarket rolling series this cap is not currently recommended: once one market reaches it, entries stay blocked in every later market of the series until you redeploy, so prefer position_size and order_count gates there. Comparisons test the relationship on each tick. {field: edge.btc.price, op: " ", value_field: edge.btc.ema_12_1m} is true on every tick where spot is above its EMA, not only on the tick it crosses. Kalshi: blocked entries fall through On Kalshi, if a matching entry (buy_yes, buy_no, or a composite orders rule) is held back because it is outside a trading schedule, or because the market is an older market of your series kept only so the Bot can manage its position, the Bot records the rule as blocked and keeps going to the next rule on the same tick. On Polymarket and Polymarket US evaluation is strictly first match. In backtests Backtests use the same top to bottom, first match logic. Rules are evaluated at each candle close, and the matched action executes at the next candle's open, so there is at most one action per candle. Kalshi and Polymarket custom strategies can be backtested; Polymarket US custom strategies cannot. Some fields are simulated or unavailable in backtests; the field catalog lists which. Recommended rule order Because the first match wins, order is behavior. A safe default: 1. Safety exits such as a stop loss or a flatten before close rule, gated on position_size 0. 2. Take profit exits, with the same gate. 3. Guards: skip to stand aside when conditions are poor, cancel_all to pull resting orders. 4. Entries, gated on position_size == 0 (or a size cap) plus a price band. Warning: Two ordering mistakes pass validation. An exit without a position gate that is true at a P&L of 0, such as unrealized_pnl = 0 on its own, matches every tick while you are flat (P&L is 0 when flat) and starves every entry below it. A skip placed above your exits blocks the exits too. Gate exits on holding a position, and keep guards below exits.36:T20ce,Custom Rule Conditions and Missing Data A condition is one comparison inside a custom rule's when block, and a rule fires only when its conditions match. This page covers how to write conditions for custom strategies on Kalshi, Polymarket and Polymarket US, then what happens when the data a condition reads is missing. For where conditions sit in a rule and how rules are checked each tick, see Rule anatomy and How rules are evaluated. Conditions Condition keys Parameter Type Default Allowed values What it does field field name none (required) A built in field, edge. . or derived. , allowed on your venue; case sensitive The live value on the left side of the comparison. op text none (required) , =, ==, != (always quoted) The comparison. See Operators. value number, or duration none A plain finite number; a duration string for time_to_expiry A fixed threshold. Exactly one of value or value_field. See value and value_field. value_field field name none Any numeric field valid for field on your venue Compares against another live field instead of a number. No other keys are allowed in a condition (unsupported condition key "operator" (allowed: field, op, value, value_field)). A condition must be a mapping, so a string such as "price = 0.30 and price " Greater than Required " =" Greater than or equal Required "==" Equal Recommended "!=" Not equal Required Always quote operators. In the one line {field: ..., op: ..., value: ...} style used throughout the Custom Rules docs, an unquoted , = or != is a YAML error. Written on its own line (op: ), an unquoted or != is read as empty (unknown operator "") and = is a YAML error. Anything else, such as =, = or contains, gives unknown operator. There are no crossover operators in custom rules. == and != compare exactly, so prefer ranges for computed values like price and unrealized_pnl: price = 0.50 is safer than price == 0.50. A comparison with an unavailable value is always false, whatever the operator. value and value_field value is a plain number. Write value: 0.4, not value: "0.4"; a quoted number is rejected with price requires a numeric value (got string) — remove the surrounding quotes. Booleans, null, .inf and .nan are rejected too. There are two exceptions: time_to_expiry takes a duration string, and a text edge field takes one of its text values. Units matter, and most mistakes here are unit mistakes: Prices and spreads are dollars per contract, from 0 to 1. Write 0.40 for 40 cents. price 40 can never be true and is rejected as contradictory; price < 40 is always true. unrealized_pnl and balance are dollars. P&L covers the whole position, not one contract. position_size, order_count and size are counts of contracts, shares or orders. Edge fields use their provider's units. NWS humidity and precipitation probabilities are fractions (0.70, not 70), and values outside 0 to 1 are rejected for them. value_field compares two live fields read from the same snapshot, for example yes_best_ask against no_best_ask, or a Coinbase price against its EMA. Both sides must be numeric fields allowed on your venue. Setting both value and value_field is rejected (exactly one of value or value_field must be set, not both), and so is setting neither. Studio does not check units across a value_field comparison. Comparing a dollar field with a seconds field saves, so make sure both sides mean the same thing. Behavior validation also cannot analyze value_field conditions; see What the checker cannot see. Durations for time_to_expiry time_to_expiry is the only built in field that takes a duration string instead of a number: a whole number followed by one lowercase unit. Unit Example Seconds s "90s" 90 m "15m" 900 h "6h" 21,600 d "1d" 86,400 Invalid forms and their errors: a bare number such as 3600 (time_to_expiry requires a duration string (e.g. "6h")), "300" with no unit (unknown duration unit "0" in "300" (want s m h d)), decimals such as "1.5h" (invalid duration magnitude "1.5"), and compound, weekly or uppercase units such as "1h30m", "1w" or "2H". Write "90m" instead of "1h30m". Durations are converted to seconds when the strategy is compiled. Edge fields measured in seconds, such as the economic calendar's seconds_to_next, take plain numbers, not duration strings. Missing or unavailable data Most missing data fails closed: rules on that data stay off rather than trading on a guess. A few values fall back to a number instead, and those are listed under Unavailable values. How that plays out depends on what is missing. Unavailable values A single value can be unavailable for a tick, for example a side of the order book that is empty, or an edge value the provider could not compute (a late Coinbase candle, an NWS forecast outage). Every comparison with an unavailable value is false, whatever the operator, including !=, and that applies to either side of a value_field comparison. The condition fails, so an all rule does not match; an any rule can still match through its other conditions. Later rules still run. Backtests behave the same way. Some fields fall back to a number instead of going unavailable: Field When data is missing price Kalshi: last trade, else 0.00. Polymarket: ask, bid, then last trade. Polymarket US: current price, then midpoint. spread A missing ask counts as 1.00 and a missing bid as 0.00, so the spread reads wide. time_to_expiry 0 when the close time is unknown, so near close exits fire and late entry gates block. unrealized_pnl Kalshi: a held side with no bid is marked at $0. Polymarket: unavailable. balance Polymarket and Polymarket US: 0.00 if it cannot be read. position_size Polymarket: a token whose balance cannot be read counts as 0, so an entry gated on position_size == 0 can match while you hold. order_count Polymarket: if the open orders read fails, only the orders that loaded are counted. NWS alert and forecast text fields also fall back rather than going unavailable: during an alert outage alert_active reads 0, and during a forecast outage precip_amount_in reads 0. See Edge Data. When entries are blocked Some situations block only new entries. Rules are still evaluated: a matching buy_yes, buy_no or composite orders rule is skipped with a blocked decision, and the rules below it, exits included, still run. Situation Kalshi Polymarket Polymarket US A declared edge alias is stale beyond its limit Entries blocked; this Bot's resting entry orders on the market are canceled Edge data not supported Entries blocked; resting orders stay A derived metric's strike or input is unavailable Entries blocked; this Bot's resting entry orders on the market are canceled Not supported Not supported After active_window.end Entries blocked in the markets it still holds or has orders in Entries blocked in its market Not supported Max daily loss reached Entries blocked until 00:00 UTC Not read Not read Outside a trading_schedule Entries blocked Not supported Not supported An exit whose own conditions read the missing edge or derived value can't fire until it is back, because those conditions are false; exits on price, the book, position or P&L run as usual. Watch data freshness in Monitoring. When the tick is skipped Two situations stop rule evaluation for a market altogether: Situation Kalshi Polymarket Polymarket US risk.max_loss has halted the strategy Rules not evaluated; the Bot cancels its orders and sells the position this run opened Not supported Not supported Before active_window.start Rules not evaluated Rules not evaluated Not supported The decision log records why the tick was skipped. Errors end the tick If reading the market or your account fails (a venue API error, for example), or a rule raises an error while being evaluated or executed, the rest of that market's tick is abandoned: no later rule runs, including exits. The next tick starts fresh. On a Kalshi series, other markets in the same cycle still run. On Polymarket, a failed read of the trade history behind unrealized_pnl does not end the tick: P&L reads as unavailable and the other rules still run. Rule level causes of errors to avoid: a Kalshi sell with no bid on that side, a Kalshi buy while either side of the book is empty, any Kalshi order while the market's most recent trade is more than 120 seconds old, a Kalshi or Polymarket US buy larger than your Max contracts per order, and a Polymarket US sell_all with no bid to sell into.37:T28d1,Custom Rule Field Catalog A field is the live value a custom rule condition reads, such as price, position_size or spread, on Kalshi, Polymarket or Polymarket US. The table below lists every field, including the edge data and derived fields you declare, with its units, venue support and backtest support; the sections after it explain how each venue computes each value. For how a condition compares a field, see Conditions. Built in fields Field What it reads Units Kalshi Polymarket Polymarket US Backtest price The YES price, computed differently per venue Dollars, 0 to 1 Yes Yes Yes Kalshi, Polymarket spread YES ask minus YES bid Dollars, 0 to 1 Yes Yes Yes Kalshi, Polymarket volume Traded volume reported by the venue As the venue reports it: contracts on Kalshi, dollars on Polymarket Yes Yes Yes Kalshi only, per candle time_to_expiry Time until the market closes Seconds, written as a duration Yes Yes Yes Kalshi, Polymarket position_size What you hold in this market, YES and NO combined Contracts or shares Yes Yes Yes Kalshi, Polymarket yes_position_size YES contracts you hold Contracts Yes No No Kalshi no_position_size NO contracts you hold Contracts Yes No No Kalshi unrealized_pnl Profit or loss if you sold the whole position now Dollars Yes Yes Not recommended Kalshi, Polymarket balance Available cash Dollars Yes Yes Yes Kalshi, Polymarket (simulated) order_count Your resting orders on this market Count Yes Yes Yes Simulated, usually 0 portfolio_position_count Markets you hold a position in across your account Count Yes No No Kalshi yes_best_bid Best YES bid Dollars, 0 to 1 Yes Yes No Kalshi yes_best_ask Best YES ask Dollars, 0 to 1 Yes Yes No Kalshi no_best_bid Best NO bid Dollars, 0 to 1 Yes Yes No Kalshi no_best_ask Best NO ask Dollars, 0 to 1 Yes Yes No Kalshi paired_best_bid_sum YES bid plus NO bid Dollars, 0 to 2 Yes No No Kalshi paired_best_ask_sum YES ask plus NO ask Dollars, 0 to 2 Yes No No Kalshi edge. . A value from an external data source you declared Provider units Yes No Yes Kalshi, per field derived. A metric you declared, such as distance from the strike Units of its input Yes No No Kalshi A field that is not available on your venue is rejected when you save. Rejections look like field "yes_position_size" is only supported for Kalshi strategies or field "no_best_ask" is only supported for Kalshi and regular Polymarket strategies. Field names are case sensitive: Price is an unknown field. Polymarket US custom strategies cannot be backtested at all. On Kalshi, position_size, the side positions and unrealized_pnl describe this Bot's attributed inventory, including positions explicitly adopted at deployment. Manual trades and other Bots' positions are excluded. balance, order_count and portfolio_position_count remain account wide. On the other venues, position fields read your account holdings. In paper trading these values come from the paper session instead: balance is paper cash, which starts at the paper starting balance ($1,000 by default). price The market's YES price in dollars. Each venue computes it differently: Kalshi: the best YES bid. With no YES bid, the most recent trade price, or 0.00 if there are no trades. Polymarket: the YES token midpoint, (best bid + best ask) / 2. It falls back to the best ask, then the best bid, then the last trade. Polymarket US: the last trade price, falling back to the venue's current price, then the bid/ask midpoint. Backtest: the candle's last trade close, else the bid/ask midpoint. price is always the YES side, even in a buy_no rule. A NO position gains when price falls. On Kalshi, buy_yes is sent at yes_best_ask, not at price, so use the order book fields for exact entry and exit prices there. On Polymarket, a buy is placed at the token midpoint (for buy_yes, the same number as price) and sells at the bid. spread YES ask minus YES bid, in dollars (0.03 is 3 cents, not 3%). A missing ask counts as 1.00 and a missing bid as 0.00, so a one sided or empty book reads as a very wide spread. That makes spread "20m" block. On Polymarket, selecting a market by token IDs only leaves the close time unknown. In backtests it is the time from the candle to the market close. position_size How much you hold in this market, YES and NO combined: Kalshi: the absolute size of this Bot's attributed net position on this market, capped at what the account still holds on that side. Kalshi nets YES and NO in one market, so buying NO while holding YES reduces the YES position. Polymarket: your YES token balance plus your NO token balance. It can be fractional, and the two tokens are held independently. If a token balance cannot be read on a tick, that token counts as 0 for the tick, so position_size can briefly read lower than what you hold: a position_size == 0 entry can match, and a position_size 0 exit can miss that tick. Keep risk.max_notional set on Polymarket custom strategies as a backstop. Polymarket US: the absolute size of your net position. Gate entries with position_size == 0 and exits with position_size 0. Behavior validation uses exactly this field to tell "flat" from "holding", so exits that are gated on it are the ones the checker can analyze. yes_position_size and no_position_size Kalshi only. The YES contracts and the NO contracts attributed to this Bot in this market, capped at the account's holdings on that side. Because Kalshi nets the two sides, at most one of them is non zero. Use them for side aware exits: yes_position_size 0 with yes_best_bid and sell_yes, or no_position_size 0 with no_best_bid and sell_no. Behavior validation cannot analyze side position conditions, so a rule that uses one is left out of the range checks. It will not stop you from writing yes_position_size 0 → sell_yes, which sells right after every entry. Always add a price, P&L or time condition to a side aware exit. unrealized_pnl The profit or loss, in dollars, if you sold your whole position in this market right now. It is 0 when you are flat. It is a total for the position, not per contract: 10 contracts that each move 2 cents change it by $0.20, so scale thresholds with your size. Kalshi: this Bot's held contracts times the held side's best bid, minus their remaining entry cost and entry fees. Other Bots' inventory and costs are excluded. If the side you hold has no bid, it is marked at $0, which reads as a large loss. A P&L stop can then match, but its sell needs a bid, so it errors on each tick until a bid appears. Polymarket: held tokens times each token's best bid, minus the entry cost and fees of the tokens you still hold, from your trade history (in paper trading, from the paper session's own fills, entry fees included). If the P&L cannot be worked out on a tick (no bid on a held side, or, on a live Bot, a trade history that cannot be read or whose recent trades do not account for every token you hold, such as a position built from older trades), the value is unavailable for that tick and the decision log notes it: P&L conditions are false, whatever the operator, and your other rules, exits included, still run. Polymarket US: not recommended. The value is read from the venue's position record and does not reliably represent profit or loss, and it is always 0 in paper trading. Build Polymarket US exits on price instead. Backtest: liquidation value at the bid minus cost and fees. Right after a buy fills, unrealized_pnl starts slightly below 0, not at 0: the position is marked at the bid, you paid the ask (Kalshi) or about the midpoint (Polymarket), and fees are subtracted. A 1 contract Kalshi buy with a 0.04 spread reads about $0.04 minus fees. Keep each P&L stop wider than the spread you allow on entry, for example with a spread condition on the entry, or the stop can fire on the tick after you buy. Behavior validation models this moment as P&L 0, so it does not warn about a stop that is too tight; it does reject an exit such as unrealized_pnl = 0 that matches at P&L 0 (see Exits that fire right after entry). balance Your available cash in dollars: the account balance on Kalshi, collateral buying power on Polymarket, buying power on Polymarket US. On Polymarket and Polymarket US it reads 0.00 if the balance cannot be read, so a guard like balance 0 → cancel_all can fire on every tick while a manual order rests. On Polymarket, if your open orders cannot be read on a tick, order_count can undercount for that tick, so an order_count == 0 gate can pass while an order rests. In ordinary backtests buys fill or skip immediately, so order_count is always 0 there. Only Kalshi composite order backtests simulate resting orders. portfolio_position_count Kalshi only. The number of different markets in which your Kalshi account currently holds a position (all Bots and manual trades). It is useful to cap how many markets you hold at once with a series or market.selection: all, for example portfolio_position_count . reads a value from an external data source (Coinbase prices and indicators, NWS weather, the FOMC/CPI economic calendar). Declare the alias under the top level edge: block and list the field in that alias's fields; otherwise the rule is rejected (edge alias "x" not declared, edge field "f" not listed in alias "x", or edge field must be edge. . ). Edge fields work in custom strategies on Kalshi and Polymarket US. Regular Polymarket rejects the edge block. Values are numbers in the provider's units: change_15m of 0.003 is +0.3%, NWS humidity of 0.70 is 70%. Text fields (NWS precip_type and alert_severity, calendar next_event_type and previous_event_type) take == or != with one of the field's values, such as {field: edge.nyc.alert_severity, op: "==", value: warning}. Values are case sensitive, and ordering operators, numbers and value_field are rejected. See Text fields. If a whole alias is stale, every field of it is unavailable and new entries are blocked for that market; exits still run. A single value that cannot be computed is unavailable too. Providers, field lists, units, refresh rules and backtest coverage are in Edge Data. Derived metrics derived. reads a metric declared under the top level derived: block, such as the signed distance between a Coinbase price and the Kalshi market's strike. Kalshi custom strategies only. If the strike or the input value is unavailable, derived fields read as unavailable, new entries are blocked, and this Bot's resting entry orders on the market are canceled. See Edge Data.38:T2abb,Custom Rule Actions The action is what a custom rule does when it is the first rule to match on a tick (see How rules are evaluated). This page covers what each action does on Kalshi, Polymarket and Polymarket US and in backtests, then how size and price bounds apply. Kalshi's composite orders, which a rule can use instead of action, are covered in Advanced Kalshi Rules. Action reference Action Kalshi Polymarket Polymarket US Kalshi backtest buy_yes Limit buy at the YES ask Limit buy at the YES midpoint Limit buy at the last trade price Fills at the next candle's YES ask buy_no Limit buy at the NO ask Limit buy at the NO midpoint Limit buy at 1 minus the last trade price Fills at the next candle's NO ask sell_yes Sells this Bot's available YES at the YES bid, immediate or cancel Limit sell of size (or all) YES at the YES bid Not allowed Sells all YES at the next candle's bid sell_no Sells this Bot's available NO at the NO bid, immediate or cancel Limit sell of size (or all) NO at the NO bid Not allowed Sells all NO at the next candle's bid sell_all Sells this Bot's available holdings, immediate or cancel at the bid Limit sell of each token you hold at its bid Market orders for the whole position, split to fit Max contracts per order Closes everything at the next candle cancel_all Cancels this Bot's resting orders on the market Cancels all your open orders in the market Cancels all your open orders on the market No effect in ordinary backtests skip Nothing; stops checking rules this tick Same Same Same Action names are lowercase. buy, sell, close or BUY_YES give unknown action. On Polymarket US, sell_yes and sell_no are rejected with use sell_all on Polymarket US. Buying: buy_yes and buy_no Kalshi. By default, a good till canceled limit buy for size contracts at the current ask, clamped into risk.price_floor to risk.price_ceiling. Because it is priced at the ask it usually fills at once; any remainder rests on the book. If the ask is above your ceiling, the order is posted at the ceiling and rests. Every buy must also pass your Studio deployment risk limits (Max contracts per order, Max open contracts, which never allows more than risk.max_position, Max dollars per order, Max daily notional traded) and your balance. A buy that would break one of them is refused with an error, not resized. Once Max daily loss is reached, a matching buy rule is skipped instead, and the rules below it still run. risk.max_notional trims the quantity to the remaining budget, and risk.max_entries_per_market can skip the buy. Set entry_execution: immediate_or_cancel on a Kalshi custom buy_yes or buy_no rule to refresh state and recheck that rule after account safety checks, just before submission. An owned pending entry in the same market blocks another submission; any unfilled remainder is canceled instead of resting. Ambiguous submissions pause further entries without an automatic retry or reconciliation. The only explicit value is immediate_or_cancel; omit the key for GTC. Sell rules, composite orders, built ins and other venues reject it. A buy limit caps the maximum price paid, not the minimum fill price, and cannot guarantee the signal remains true at exchange match time. See Kalshi custom rules. Kalshi entries also wait while the account holds contracts in this market that are not attributed to this Bot. Its existing holdings can still exit. Both sides of a Kalshi book must have orders when the buy is sent; otherwise the buy errors for that tick. Because price falls back to the last trade (or 0.00) when there is no YES bid, a price only entry can match on an empty book and then error. Gate Kalshi entries on spread or on the order book fields, which fail safe when a side is empty. Polymarket. A good till canceled limit buy at the token's midpoint, rounded down to the market's tick and clamped to your price bounds, so it can rest instead of filling. The buy is skipped while any of your orders rest in the market, unless risk.max_entries_per_market is set. The quantity is size shares, trimmed to risk.max_position minus what you hold and to the remaining risk.max_notional budget. If the result is below the market's minimum order size (commonly 5 shares), the entry is blocked. Polymarket holds YES and NO tokens separately, so buying NO does not reduce a YES holding. Polymarket US. A good till canceled limit buy at the last trade price (buy_yes) or 1 minus the last trade price (buy_no), clamped to your price bounds. It is skipped while any of your orders rest on the market, and it needs buying power, a two sided book and your Studio deployment risk limits. Backtest. Execution depends on the replay. Kalshi's execution engine replay clamps the submitted buy limit into the price band and can fill at the next executable event even if the signal has changed or the fill is below price_floor. IOC entries with an L2 book fill only against available depth within the limit and cancel the remainder; they may fill partly or not at all. Other candle paths can skip out of band buys. If you hold the opposite side, it is sold first. A buy rule without a position_size == 0 gate (or a similar cap) matches on every tick and keeps adding until a risk limit stops it. Selling: sell_yes, sell_no and sell_all Kalshi. Sells this Bot's available holding of the side (or, for sell_all, whichever side it holds) with reduce only, immediate or cancel limit orders at the best bid. Every exit, including composite orders, is capped at the Bot's attributed inventory and the account's remaining holdings. Pending or unconfirmed exits reserve inventory so it cannot be submitted again. These checks apply with or without a trading schedule. Large positions go out in chunks of up to 40 contracts, or your Max contracts per order if that is lower. Fractional fills can leave fractional holdings: exits round available inventory down to 0.01 contracts, correcting tiny floating point residue near whole numbers before splitting. For example, 49.99 contracts split into 40 and 9.99 when the per order limit allows it; a residual below 0.01 is not submitted. Whatever does not fill is canceled, and the rule tries again on the next tick if it still matches. An accepted exit order does not prove it filled or that the position is flat. size is ignored. With no bid on that side, the sell errors for that tick. Sells are not clamped to your price bounds. Kalshi also refuses any order, sells included, when the market's most recent trade is more than 120 seconds old, so on a quiet market an exit can be refused until a fresh trade prints (see Kalshi units and execution). Polymarket. sell_yes and sell_no place a good till canceled limit sell of size tokens (all of them if size is omitted) at that token's best bid, rounded up to the tick. This is how you scale out. Sells are not clamped to your price bounds, so a stop loss with the bid below risk.price_floor sells at the bid. If the token has no bid, the sell is priced from that token's ask or last trade and may rest unfilled. Do not rely on selling into an empty book. Unlike buys, Polymarket sells are not held back while your orders rest: if a sell rests unfilled and the rule still matches on the next tick, it places another sell. Add order_count == 0 to scale out rules. sell_all places a limit sell of the full balance of each token you hold, at its best bid, or its best ask when there is no bid; a token with no book price is skipped. Polymarket US. Only sell_all is allowed. It sells your whole position with market orders, split into orders of at most min(40, Max contracts per order) contracts. It needs a bid to sell into, and it is refused if the side you hold cannot be determined. Backtest. Every sell closes the whole side at the next candle's opening bid. A sell that matches while you are flat does nothing, but it still ends evaluation for that tick. Selling does not cancel your resting orders; add a cancel_all rule if they should come down too. cancel_all Cancels resting orders on the current market. It does not sell anything. Kalshi: cancels only this Bot deployment's own resting orders. Manual orders and other Bots are untouched. Polymarket and Polymarket US: cancels only the orders this Bot placed, which it recognizes by the order ids the exchange accepted from it. Manual orders and other Bots are untouched. Backtest: no effect in ordinary backtests (orders never rest); it cancels simulated resting orders in Kalshi composite order backtests. cancel_all satisfies the required exit rule, but it never reduces a position. skip Places no order and stops checking rules for this market until the next tick. Use it as a guard above your entries, for example to stand aside when the spread is wide or cash is low. It does not count as an exit, and a skip above your exits blocks them. Its conditions still count when the validator looks for unreachable rules, so a skip that matches every state is rejected. Size rules size is a whole number of contracts (Kalshi, Polymarket US) or shares (Polymarket). It is a quantity, not dollars: 12 contracts at $0.39 cost $4.68 before fees. Buys: omitted or 0 means 1. Negative sizes are rejected. Save time limits: a buy's size must be at most risk.max_position, and size × risk.price_floor must fit inside risk.max_notional when that is set. Whole numbers only. size: 1.9 fails with rules[0].size: must be a whole number, got 1.9, and so does a fractional orders[].size. A quoted size (size: "2") is a YAML error. Kalshi and Polymarket US: your Studio deployment risk limits apply at runtime. Studio pre fills Max contracts per order from the largest buy size across your rules (an omitted size counts as 1). A buy larger than the limit you deploy with is refused, not shrunk. On Polymarket US a sell_all larger than it is split to fit. Polymarket: a buy below the market's minimum order size is blocked, so an omitted size (1 share) usually never trades. The quantity is also trimmed by risk.max_position and risk.max_notional. Sells: size is ignored, except by Polymarket sell_yes / sell_no, where it caps how many tokens are sold. Backtests: buys are trimmed to risk.max_position minus your position, and sells close the whole side. In a multi market backtest with risk.max_notional set, a buy with no size buys as many contracts as the remaining budget allows, which differs from live. Write size on every buy rule so live and backtest agree. Price bounds risk.price_floor and risk.price_ceiling bound order prices differently by venue: Kalshi clamps buy prices only, Polymarket clamps buys and tick rounds every order, and Polymarket US clamps buys. Backtest behavior depends on the replay: Kalshi execution engine buys clamp the limit, so an executable fill below the floor is still possible; other candle paths can skip out of band buys. To avoid resting bids when the market is above your limit, put the limit in the rule itself, for example yes_best_ask <= 0.60.39:T1227,Custom Rule Validation When you save a strategy: custom strategy on Kalshi, Polymarket or Polymarket US, Studio validates it before it can run. This page covers the three validation passes, the exit rule every custom strategy needs, the behavior checks that catch rule sets whose logic is broken, and the mistakes those checks cannot catch. Worked examples of each behavior check are on Exit Checks and Entry Checks. What happens when you save Studio checks a custom strategy in three passes: 1. Structure. Unknown keys, a rule with no name, a when with both or neither of all/any, a rule with both or neither of action/orders, and an empty rule list are rejected. 2. Fields, values and actions. Fields must exist and be allowed on your venue, operators must be valid, values must have the right type, and at least one rule must be an exit. 3. Behavior. If the first two passes succeed, Studio checks whether your rules make sense together. This catches rule sets in which every key is valid but the logic is broken. Each error has a path such as rules[1].when.all[0].op and a message. Behavior errors also name the rules involved and include a sample state that shows the problem. The rejected examples here and on the Exit Checks and Entry Checks pages are complete strategies that Studio refuses. Each lists the error text it produces, followed by a corrected version that saves. The required exit rule Every custom strategy needs at least one rule whose action is sell_yes, sell_no, sell_all or cancel_all, so positions cannot only grow. buy_, skip and composite orders rules do not count. Polymarket US rejects sell_yes and sell_no, so there only sell_all and cancel_all count, and the error names only those two. Fixed: add a stop loss and a take profit with a gap between them. The entry also gets a spread limit, so the $0.10 stop is wider than the spread paid on a 1 contract entry (see unrealized_pnl). Behavior checks Each check name links to a worked example: a rejected strategy and a version that saves. Check Error message Rejected when Fix contradictory_predicate predicate is contradictory and can never match The conditions of an all block can never be true together, or a threshold is outside the field's range (price 1, position_size = 0, price 0. The sampled entry/exit loop check also enforces book relationships: bids cannot exceed their asks, YES and NO bids sum to at most 1, asks sum to at least 1, and paired sums match their component quotes when both are sampled. A loop that requires an impossible crossed book is not rejected. For example, buying YES at an ask of $0.43 or less and selling at a bid of $0.57 or more requires a price move; those bands alone do not cause an immediate loop. Exits only count as exits here when they are sell_yes, sell_no or sell_all; cancel_all never sells, so it is ignored by the three exit checks. What the checker cannot see Behavior validation catches common logic mistakes, not all of them. A strategy that saves can still be wrong. You are responsible for these: Conditions it cannot turn into a range. A rule that contains any edge. field, any value_field comparison, any time_to_expiry condition, or yes_position_size / no_position_size is left out of the contradictory, always matches, unreachable and exit coverage checks, and it never counts as covering later rules. Its buy size is still checked, and the loop check still runs, but there an edge, duration, side position or derived condition never matches (a value_field comparison between two built in fields can still match). So yes_position_size 0 → sell_yes together with yes_position_size == 0 → buy_yes saves even though it loops, and an entry of only time_to_expiry = "0s" saves even though it is always true. Condition order inside all. One exception to the point above: the checker reads an all list top to bottom, and if the conditions before the first unanalyzable one already contradict each other, the rule is still rejected. So all: [price 1, time_to_expiry "5m"] is rejected but the same two conditions in the opposite order save. Ungated exits that are true while flat, such as unrealized_pnl = 0 without position_size 0. They starve every entry below them. A skip placed above your exits. See Recommended rule order for how to order exits, guards and entries. Unit mistakes that happen to stay in range. yes_best_ask 0 together with position_size < 1 is not flagged. Rules with a trading_schedule or per fill exits get only some of the checks; see Advanced Kalshi Rules. The loop check is a sample. It tries a limited set of prices and states, so passing it does not prove your rules cannot alternate.3a:T84e,Custom Rule Exit Checks When you save a strategy: custom strategy, Studio's behavior checks reject exit rules that would never let the Bot hold a position, or that sell right after each entry. Each section below shows one of the three exit problems they catch as a rejected strategy (Kalshi or Polymarket US) with the error text it produces, followed by a corrected version that saves. For contradictions, unreachable rules and entry problems, see Entry Checks. Selling whenever you hold This is the most common rejection. An exit whose only condition is position_size 0 sells in every state you could hold in: profitable, neutral and losing. It also means the Bot sells right after each entry. One rule trips three checks: Fixed: give each exit a reason that is false right after entry. On Polymarket US, exits are written on price (see unrealized_pnl). A plain sell rule gated only on a larger holding, such as position_size = 2, is allowed, because it does not fire while you hold a single contract. Exits that leave no hold zone Taken together, your exits must leave some held state in which no exit fires. Otherwise the Bot can never keep a position. The usual cause is a stop loss and a take profit whose thresholds overlap, here because they were swapped: Fixed: the Bot holds while the YES price is between 0.30 and 0.60, and the entry band sits inside that zone. Exits that fire right after entry Right after a buy fills, the position exists and prices have not moved. The validator models that state as P&L $0.00 (live, it starts slightly below 0 because of the spread and fees; see unrealized_pnl). If the first rule that matches that state is an exit, the Bot sells, is flat again, and the same entry buys again on the next tick: a buy sell loop that only pays spreads and fees. The validator simulates this on sample states and rejects the loop. Fixed: the take profit needs the position to gain $0.20 first. The same applies to price exits: if your entry buys at price <= 0.40 and your exit sells at price < 0.50, every entry price is also an exit price. Put the exit threshold on the far side of the entry band.3b:T817,Custom Rule Entry Checks When you save a strategy: custom strategy, Studio's behavior checks reject rules that cannot work as written: conditions that contradict each other, entries that match every state, rules that earlier rules make unreachable, and buy sizes that break your risk block. Each section shows a rejected strategy with the error text it produces, followed by a corrected version that saves; the examples use Kalshi and Polymarket. For the three checks that apply only to exits, see Exit Checks. Contradictory conditions A rule whose conditions can never all be true, or that compares against a value outside the field's range, can never fire. The classic case is writing cents instead of dollars: Fixed: write the threshold in dollars. On Polymarket, price is the YES midpoint and the buy is a limit order at that midpoint, so order_count == 0 keeps the entry from stacking on an unfilled order. Size 10 clears the common 5 share minimum. The same check rejects bands that do not overlap, such as price = 0.80 together with price = 0, position_size = 0, and price < 50 (cents again, always true for a 0 to 1 price). Unreachable rules If earlier rules already match every state a rule could match, that rule can never fire. Earlier skip and cancel_all rules count. Here the broad dip entry sits above the narrow one: Fixed: put the narrower rule first. Studio pre fills Max contracts per order from the largest buy size, here buy_deep_dip with 2, so both buys fit that deployment limit. If you lower it to 1 when deploying, the 2 contract buy is refused at runtime; see Size rules. Entry sizes that break your risk block A buy's size is checked against the strategy's risk block when you save: it must be positive, at most risk.max_position, and size × risk.price_floor must not exceed risk.max_notional when that is set. An omitted size counts as 1. Fixed: size the entry within risk.max_position. The save time check covers buy_yes and buy_no rules only. Composite orders sizes are not checked against risk.max_position, so keep them within it yourself.3c:T1254,Custom Rule Example Strategies This page collects seven complete custom strategies that save as written: three for Kalshi, two for Polymarket and two for Polymarket US. The markets are placeholders and the numbers are small illustrative values, not recommendations: replace them with your own after you understand what each rule does. For what each key, field and action means, start at Custom Rules. Kalshi: flatten before close with side aware exits Buy one cheap YES contract on a rolling Kalshi series, take profit or stop out on the YES bid, flatten 5 minutes before close, and cap how many markets the account holds at once. The exits come first; the entry is last. It holds while the YES bid is between 0.25 and 0.60, and the entry only buys at a YES ask of 0.30 to 0.40, so with a spread of at most 0.03 the bid starts inside that zone. Because the exits use yes_position_size and time_to_expiry, the checker cannot analyze them, so that hold zone is yours to keep. portfolio_position_count counts every market with a position in the Kalshi account, including other Bots and manual trades. Kalshi: P&L bracket with a spread and balance gate Buy NO when YES trades rich, exit on a dollar stop loss or take profit, and stand aside when the book is wide or cash is low. The any guard sits below the exits so it never blocks a stop. The checker can analyze every rule here: the Bot holds while P&L is between $0.15 and +$0.20. Kalshi: comparing two live fields Two value_field comparisons on one entry: Coinbase spot above its 1 minute EMA 12, and the YES ask below the NO ask. Both are tested on every tick, not only at the moment they cross. The spread limit keeps the $0.20 stop wider than the spread paid at entry. If the Coinbase alias goes stale, entries are blocked and this Bot's resting entry orders on the market are canceled, while its three exits, which read no Coinbase field, keep running. Polymarket: order book rules Buy NO from the book on a pinned Polymarket market and exit on the NO bid. The entry requires the NO bid to already sit inside the 0.15 to 0.55 hold zone; without those bounds the validator would reject the rules as an entry/exit loop, because it considers every combination of bid and ask. A cancel_all pulls an unfilled buy once the NO ask moves away. Try a Paper Run on live prices with simulated money. The buy is a limit order at the NO midpoint, so it may rest. 20 shares clears the common 5 share minimum, and at a midpoint of $0.35 or less they cost at most $7 of the $10 max_notional budget. cancel_all cancels only this Bot's orders, never ones you placed by hand. Polymarket: dip buyer that scales out A recurring 15 minute Up/Down market using price, spread, time_to_expiry, position_size and order_count. Try a Paper Run on live prices with simulated money. The entry band (0.30 to 0.40) sits above the 0.25 stop, so the Bot does not stop out on the tick after it buys. sell_yes with size: 5 sells half of a 10 share position. Once that sell fills, position_size is 5, so the scale out rule cannot fire again; order_count == 0 stops it from placing a second sell while the first one is still resting. The $5 max_notional applies to each 15 minute market separately; between $0.30 and $0.40, 10 shares cost $3 to $4. Polymarket US: weather driven NO An NWS forecast gates the entry, a second condition cancels an unfilled buy if the forecast turns, and the exits use price because Polymarket US has no sell_yes / sell_no and its unrealized_pnl is not reliable. Studio pre fills Max contracts per order at 1 from that size (see Size rules), and a larger sell_all would be split to fit anyway. If the NWS alias goes stale, entries are blocked while the price exits keep running. Polymarket US custom strategies cannot be backtested. price is the YES last trade on Polymarket US, and buy_no is sent at 1 minus that price, so the NO position gains as price falls. The entry band (above 0.30, up to 0.60) sits inside the exits' 0.15 to 0.75 hold zone, so the Bot does not stop out right after it buys. Polymarket US: calendar window with a cash guard Enter YES in a window before an FOMC statement, cancel an unfilled entry in the final hour, flatten 45 minutes before the statement, and stand aside when buying power is low or the spread is wide. The calendar value is a snapshot taken at each refresh, so it can lag by up to one refresh (5 minutes here), and by up to three refreshes (15 minutes) while the calendar source is failing. seconds_to_next is a plain number of seconds (2700 is 45 minutes, 172800 is 48 hours); a duration string is rejected for edge fields. For more on building and refining strategies with Studio's AI, see Prompting.3d:T3586,Advanced Kalshi Rules Kalshi custom strategies can extend a rule in three ways. Composite orders rest limit buys priced from the live order book. Per fill exits manage each purchase at its own price. Rule level schedules give one entry rule its own trading hours. This section covers every key, how it behaves live, in paper trading and in backtests, and the combinations the validator refuses. The section is split into the pages listed under In this section: one page per feature, plus a page of complete example strategies. This page covers what applies to all three features: where the keys work and which ones can be combined, rule order, save time and deploy checks, validator messages, and how each feature runs in paper trading and backtests. Everything here builds on the rule model in Custom Rules: every loop, rules run top to bottom and the first rule that matches acts. Note: The examples use small, illustrative sizes, prices and thresholds to show how each key works. They are not recommendations, and nothing in this section suggests a strategy will make money. Backtest and paper trade any strategy before you deploy it live, and keep first deployments small. In this section Composite Orders and max_combined_price: Composite orders that rest one or two limit buys priced from the live book: how legs are priced and sized, what one firing does, keeping a quote in the queue, the max_combined_price cap for paired YES/NO quotes, and Deep Research sweeps for paired quotes. Per Fill Profit Targets and Stops: Per fill exits on sell_yes/sell_no rules: how fills become lots, entry_profit_offset, entry_stop_loss_offset, entry_profit_targets tables, entry_profit_min_time_to_expiry, and when the Bot blocks trading because it can't trust its lots. Rule Level Trading Schedules: A trading_schedule on individual buy_yes/buy_no rules for time varying entry thresholds: how it combines with the top level schedule, orders at window edges, overnight and overlapping windows, and format rules. Advanced Kalshi Rule Examples: Complete strategies that pass Studio's save checks: a paired YES/NO quote with a combined cap, a NO bid under the ask, per fill targets and stops, an entry price profit table, time varying entry thresholds and one target table for YES and NO fills. The last example shows a combination the validator rejects. Overview Feature Keys Goes on Orders it sends Composite orders orders, max_combined_price A rule with no action Resting limit buys (maker), priced from the book Per fill exits entry_profit_offset, entry_stop_loss_offset, entry_profit_targets, entry_profit_min_time_to_expiry sell_yes or sell_no rules Immediate or cancel, reduce only sells (taker) Rule level schedules trading_schedule inside a rule buy_yes or buy_no rules No new orders: limits when that rule may buy All of them need platform: kalshi and strategy: custom. Where these keys don't work Custom Polymarket and Polymarket US strategies reject them when you save. Built in strategies such as spread_capture reject per fill exits and rule level schedules. A Polymarket US built in rejects any rules block, so composite orders fail at save there too. Kalshi and Polymarket built ins don't check orders or max_combined_price, but those keys never trade live on a built in strategy. Leave them out: a stray orders block still changes the backtest (a Kalshi backtest switches to the maker replay, and a Polymarket backtest fails). Kalshi Perps and Arbitrage strategies ignore these keys without an error. Perps has its own exits; see Kalshi Perps. What can be combined Advanced strategies come in two shapes that don't mix. A quoting strategy rests composite orders and exits whole positions with sell_all, pulling quotes with cancel_all. A taking strategy enters with buy_yes/buy_no, and can add per fill exits and rule level schedules. The validator enforces the split: If you write You get Both action and orders on one rule, or neither "set exactly one of action or orders". orders: [] counts as no orders. orders anywhere plus any per fill exit key anywhere "entry relative exits do not support composite maker orders" orders anywhere plus a rule level trading_schedule anywhere "cannot be combined with composite order intents". A top level trading_schedule is allowed with orders. A rule level trading_schedule on a rule that isn't buy_yes or buy_no "supported only on Kalshi custom buy_yes/buy_no rules" A rule level trading_schedule plus a top level active_window "cannot be combined with active_window" entry_profit_offset and entry_stop_loss_offset on one rule "use separate rules for entry_profit_offset and entry_stop_loss_offset" entry_profit_targets plus either offset on one rule "use separate rules for table targets and offsets" A per fill exit with size, or on an action other than sell_yes/sell_no "requires sell_yes or sell_no without size or orders; quantity comes from each fill" max_combined_price without exactly one YES and one NO leg "requires exactly one YES and one NO order" entry_profit_min_time_to_expiry without entry_profit_targets on the same rule "requires a positive whole number s, m, or h duration and entry_profit_targets" Rule order and requirements First match wins, so the order of rules decides what happens when several could act. A reliable order, top to bottom: 1. Safety exits. Whole position sell_all or cancel_all rules for conditions where you want out regardless, such as close to expiry or around a scheduled announcement. 2. Per fill stops. entry_stop_loss_offset rules. 3. Per fill profit targets. entry_profit_offset and entry_profit_targets rules. 4. Entries. buy_yes/buy_no rules, with or without their own schedules, or a composite quote rule. 5. Fallback cancel. A cancel_all that clears resting orders once the entry conditions stop holding. Exits sit above entries so an exit always wins over new risk in the same loop. Per fill rules fall through when no lot qualifies (how a per fill rule matches), so they don't block the entries below them. A scheduled entry falls through when its window is closed (how the two schedules combine). Two limits on the fallback. First, a composite rule that stops with an error skips the rest of that market's rules for the loop, fallback included. Errors include a missing book side, a post only cross, a leg Kalshi rejects, and a leg refused by a deployment risk limit or your buying power; see What one firing does. Second, a matched sell_all doesn't cancel resting orders, so pair it with a cancel_all where needed. Save time behavior checks Studio's behavior checks treat advanced rules differently: A buy_yes or buy_no rule with its own trading_schedule is exempt from "entry predicate is exhaustive". An entry whose conditions always match is allowed when its window limits it. Rules with a rule level schedule or a per fill exit key never make the rules below them unreachable. Per fill rules also don't count toward "exit rules collectively match every held position state" or "exit predicate fires in profitable, neutral, and losing states". That's why a per fill rule gated only on yes_position_size 0 saves. An earlier rule without a schedule or per fill key can still make a scheduled or per fill rule below it unreachable. Composite orders rules aren't checked as entries, so a quote rule whose conditions always match still saves. A composite rule can still make the rules below it unreachable, and it never counts as the required exit rule. Before you deploy Start flat in every market a per fill strategy may trade, with no resting orders there. How fills become lots explains why. Keep those markets to this Bot. No manual trades and no other Bot on the same account and market. Check the deploy dialog limits. Studio prefills Max contracts per order from your largest buy or leg (see Leg size). Make sure Max open contracts and max_position both cover held + resting + new legs, and remember per fill exits sell at most Max contracts per order per loop. Deploys through MCP size their defaults from the strategy the same way. Include an exit rule. Every custom strategy needs at least one sell_all, cancel_all, sell_yes or sell_no rule. Mind max_entries_per_market with pairs. Each leg uses one entry, so a paired quote needs at least 2. Common validator messages Field level mistakes in composite legs, per fill exits and rule schedules, and the message each one gets when you save. For combinations the validator refuses, see What can be combined. Mistakes specific to max_combined_price are listed on the composite orders page. Mistake Validator message side: YES, or anything other than yes/no "side must be yes or no" action: sell in a leg "only buy order intents are currently supported" Two YES legs on one rule "duplicate order intent for yes/buy" size: 0 (or 0.9, which is cut to 0) "must be 0" reference: midpoint, or no reference "unknown price reference" An offset of 1 or more, or 1 or less "offset must be between 1 and 1 dollars" price: 0.45, or an extra key inside price A YAML error, or "unsupported price key" A per fill offset of 0, a negative value, or 1 or more "must be finite and greater than 0 and less than 1 dollars" entry_profit_targets: [] "must be a nonempty list of entry_price and target_price rows" A row with more than four decimals, a duplicate, or a not higher target "requires unique entry prices and higher target prices with at most four decimals between 0 and 1 dollars" timezone: EST, or trading_schedule: {} "timezone must be an IANA name such as America/Chicago, or UTC" trading_hours: [] with no other window list "provide between 1 and 32 windows" trading_hours: [] next to blackouts "omit unused window lists instead of providing an empty list" start equal to end, or "24:00" as a start "use distinct HH:MM start/end times; 24:00 is allowed only as end" A repeated day "days must be unique mon through sun" Backtests and paper trading All three features run in paper trading. In backtests, each one needs a specific mode: Feature Paper trading Historical backtest Composite orders and max_combined_price Yes. A resting leg fills in full at its limit once the live opposite best quote moves strictly through it. The post only check behaves as live. Kalshi maker replay only. Refused when the strategy sets risk.max_notional ("risk.max_notional enforcement is not simulated for maker backtests yet"). Per fill exits Yes. Each exit fills in full or not at all. Taker backtests only. The starting account must be flat. Rule level trading_schedule Yes, including exchange side expiry Taker backtests. A pending entry expires at the next window edge. Maker replay versus live Any rule with orders sends the whole strategy to the Kalshi maker replay, the backtest mode for resting orders. It models your place in the queue from the historical book and trades. When complete historical market data isn't available, it falls back to an approximate model that assumes you're at the front of the queue, which is optimistic. Read replay results with these differences in mind: Queue position. The replay keeps an unchanged quote in place instead of cancelling and re sending it every loop, so it can show queue priority a live quote rule without an order_count gate never gets. Only three kinds of rule act. Rules with orders, cancel_all and sell_all do something in the replay. A matched buy_yes, buy_no, sell_yes, sell_no or skip rule does nothing there but still ends evaluation for that moment. So a sell_yes stop in a quoting strategy works live but does nothing in its backtest, and it also blocks the quote rule below it while it matches. Use sell_all and cancel_all for exits in quoting strategies you want to backtest. sell_all cancels quotes in the replay, but not live. Add an explicit cancel_all so live behavior matches. Limits count differently. The replay checks risk.max_position per outcome as each order arrives, and counts max_entries_per_market by filled orders only. Live counts resting orders too. Price steps come from the market data. Legs move to the market's valid prices as they do live. If the historical data didn't record a market's price steps, the replay uses whole cents, so on a market with 0.1¢ steps it prices legs to the cent. Post only crosses are rejected when the order arrives, after modeled latency, instead of stopping the rule beforehand. A leg that isn't post only and would cross also rests at its limit instead of trading immediately. Per fill exits in backtests Per fill exits run in taker backtests; the maker replay rejects them ("entry relative exits are not supported by maker replay; use taker execution"). The simulated starting account must be flat; otherwise the backtest is refused with "entry relative exits require a flat historical starting account". Stops and targets are judged on the bid, and an exit fills on the next event only if there is enough depth at its price. Targets round up and stop prices round down to the market's own price steps, as they do live. A 0.989 fill with a 0.01 entry_profit_offset sells at 0.999 on a market with 0.1¢ steps, while on a whole cent market its target would be 1.00, so it never sells. If the historical data didn't record a market's price steps, the backtest uses whole cents. Exit size per event is the smallest of the lot, 40, and the backtest's Max contracts per order. When the backtest isn't given risk limits, that limit defaults to risk.max_position. Live, it is the Max contracts per order you deploy with, which Studio prefills from your largest buy size or composite leg. Entries are capped by the same limit, so a lot normally sells in one order in both. Give the backtest the same risk limits as your deploy to compare like with like.3e:T2f35,Composite Orders and max_combined_price This page covers composite orders in Kalshi custom strategies (platform: kalshi, strategy: custom): rules that rest one or two limit buys priced from the live order book, the max_combined_price cap for paired YES and NO quotes, and the settings Deep Research can sweep for a paired quote. Composite orders can't share a strategy with per fill exits or rule level schedules; see What can be combined. Rule order, deploy checks and how the maker backtest differs from live are on the Advanced Kalshi Rules page. Composite orders A composite rule swaps action for orders: one or two limit buy orders (legs) that rest on the book until they fill or the Bot cancels them. Each leg is priced from the live book when the rule fires, as its outcome's best bid or best ask plus a signed offset. Use them to improve a bid by a cent, rest a bid just under the ask, or quote YES and NO together. Parameter Type Default Allowed values What it does orders list none 1 or 2 legs: at most one YES buy and one NO buy Replaces action with resting limit buys orders[].side string required yes, no (lowercase) The outcome the leg buys, and whose book its reference reads orders[].action string required buy Only buying is supported. Exit with sell_all, sell_yes or sell_no rules. [orders[].size](#leg size) integer required Whole number above 0 Contracts for this leg orders[].price mapping required Keys reference and offset only A relative price. There is no fixed price form. [orders[].price.reference](#pricereference) string required best_bid, best_ask The top of book price the leg is anchored to [orders[].price.offset](#priceoffset) number (dollars) 0 Above 1 and below 1 Added to the reference: 0.01 is one cent higher [orders[].post_only](#post_only) boolean false true, false, unquoted ("true" in quotes is a YAML error) Refuse to send a leg priced at or through the ask max_combined_price number (dollars) none Above 0, at most 1 Hard cap on the YES + NO leg prices of a pair A one leg quote that improves the YES bid by a cent looks like this: How leg prices resolve All legs are priced from the same order book snapshot, the one the rule's conditions were checked against. Kalshi has one book per market, so each outcome's ask comes from the other outcome's bid: Leg best_bid means best_ask means side: yes The top YES bid 1 − the top NO bid side: no The top NO bid 1 − the top YES bid Leg price = reference + offset, clamped into your risk.price_floor to risk.price_ceiling band, then moved to the closest valid price on that market. Choose a band containing valid market prices; if it contains none, rounding can exceed the ceiling (see price bounds). Most markets step in whole cents; some allow 0.1¢ steps, such as 0.999. With max_combined_price set, the Bot then adds the two leg prices and compares the sum with the cap. orders Legs are good till cancelled limit buys. A leg keeps resting until one of these happens: it fills, the composite rule fires again (it cancels and re sends every leg), a cancel_all rule fires, the top level trading_schedule closes, active_window ends, or a risk halt stops the Bot. A sell_all rule does not pull resting legs in live or paper trading. It only sells contracts you hold. Put a cancel_all rule next to it if the quotes should come down too. Both legs go out in one request, but they are separate orders: one can fill while the other keeps resting. If Kalshi rejects one leg, the Bot cancels the leg it accepted and logs an error. Every leg counts as an entry, so entry limits see it: risk.max_entries_per_market counts each leg. When entries already used plus the legs in the batch exceed the cap, the whole batch is skipped. A pair needs 2, so max_entries_per_market: 1 blocks every paired quote. A leg that fills keeps its entry for the rest of the run. Unfilled legs that the Bot cancels free theirs. risk.max_notional is checked against the whole batch (size × limit price, summed over the legs). A batch that doesn't fit is skipped, never shrunk. risk.max_portfolio_positions applies to a composite rule in a new market, as it does to any entry. Buying power: the combined cost of every leg must fit your available balance. The top level trading_schedule gates a composite rule like any other entry, and the Bot cancels resting legs when the schedule closes. Series rollover: on a rolling series_ticker, a composite rule can't quote a market the Bot keeps only to manage positions after the series moves on. It is logged as blocked (market_not_current) and evaluation moves on to the next rule. Leg size orders[].size is the leg's contract count: a whole number above 0. A quoted "1" is a YAML error, and a fraction such as 1.5 fails with rules[0].orders[0].size: must be a whole number, got 1.5. With max_combined_price, the YES and NO sizes must be equal. Leg sizes meet your deployment risk limits, which you confirm when you deploy: Max contracts per order and Max dollars per order apply to each leg. Studio prefills them from the strategy's largest single order, which includes leg sizes: legs of size 2 prefill 2 contracts and $2. Raise Max dollars per order if a leg costs more than it allows; otherwise the Bot refuses every batch. Max open contracts counts what you hold, plus your resting orders, plus every new leg. The Bot applies the lower of it and risk.max_position. Max daily notional counts each leg. A leg over Max contracts per order, Max dollars per order, Max open contracts or Max daily notional, a new market past max_portfolio_positions, or legs that cost more than your buying power stop the rule with an error. By then the Bot has already cancelled its old quotes. The rest of that market's rules, including a fallback cancel_all, are skipped for that loop. A rule level size: on a composite rule does nothing to the orders sent, so leave it out. The validator adds up a composite rule's buy legs and rejects a rule whose legs together exceed risk.max_position ("composite buy orders together exceed risk.max_position from an empty position"), because every leg rests at once. Live, a batch that would take held plus resting contracts past the lower of max_position and Max open contracts is refused. price.reference best_bid anchors the leg to its own outcome's top bid: offset 0 joins the bid, 0.01 improves it by a cent. best_ask anchors to its own outcome's ask: offset 0.01 rests one cent under it. If the price a leg needs is missing because that part of the book is empty, the rule stops with the error "cannot resolve yes best_bid from an incomplete book". Nothing is cancelled, and the rest of that market's rules are skipped for that loop, including a fallback cancel_all below it. Gate the rule on the book fields it relies on, such as yes_best_bid 0.05 or paired_best_bid_sum 0.035 passes where paired_best_bid_sum Two things follow from the order of these steps. First, the cancel happens before the limit checks, so a refused batch leaves the market with no quote until the rule next fires successfully. Second, the log records the rule as fired even when the batch was then skipped. Look for the blocked entry next to it (max_combined_price, entry_cap, max_notional or order_batch) to see why nothing was placed. order_batch blocked means the batch was held back by order pacing, by the order attempt budget (by default 20 order attempts per 60 seconds, where each leg counts as one attempt), or by a pause after Kalshi rate limits the account (2 seconds at first, doubling while the refusals continue up to 30 seconds, unless Kalshi asks for a different wait). A batch refused by a deployment risk limit, by max_portfolio_positions or by your buying power is an error instead: the rule is not logged as fired, and the rest of that market's rules are skipped for the loop. Keeping a quote in the queue A composite rule cancels and re sends its legs on every loop where it matches, even if the prices haven't changed. Each re send puts your order at the back of the queue at that price. To let a quote rest: 1. Gate the quote rule on order_count == 0, usually with position_size == 0. 2. Put a separate cancel_all rule above it for the conditions that should pull the quote: someone outbid you, the spread collapsed, the market is near close. Your own quotes are part of the book the next loop sees. After a +0.01 bid rests, yes_best_bid, no_best_bid, paired_best_bid_sum and spread all include it. A gate such as spread = 0.03 can then fail because of your own bid, a fallback cancel_all pulls it, and the rule quotes and cancels on alternate loops, or chases its own bid up a cent at a time. Pick thresholds that account for your own quote, as the examples do. Also keep in mind: Each firing cancels all of this Bot's resting orders in that market, including resting buy_yes/buy_no orders from other rules. order_count counts every resting order your account has in the market, including ones you placed by hand. Book fields are computed in floating point, so a true 3 cent spread can come out as 0.0299999. Thresholds set halfway between cents, such as spread 0.025, avoid that edge. max_combined_price A hard cap, in dollars per YES + NO pair, on what a paired quote may cost. It goes on a composite rule with exactly one YES leg and one NO leg of equal size, and it is checked right before the Bot sends the pair. Parameter Type Default Allowed values What it does max_combined_price number (dollars per pair) none (no cap) Above 0, at most 1 Skips the pair when YES price + NO price is above the cap The exact check The Bot prices both legs first: reference plus offset, clamped to the price band and moved to the closest valid price. A missing book side or a post only cross stops the rule before this point. Then it adds the two final prices: Sum at or under the cap: the pair continues to the normal path. The Bot cancels its old orders in the market, runs the limit checks and sends both legs. Sum over the cap: the Bot cancels all of its resting orders in that market, skips the pair, and logs a blocked max_combined_price decision with the combined price and the cap. When both legs fill, Kalshi nets your YES and NO contracts in the same market. position_size returns to 0, and each completed pair locks in $1 minus the combined price, before fees. A cap of 1 allows pairs that cost the full $1 payout. Those pairs gain nothing before fees and lose money whenever fees apply. Cap versus paired_best_bid_sum paired_best_bid_sum is a condition field: the raw YES best bid plus the raw NO best bid, including your own resting quotes. It ignores your offsets and the price band. It makes a readable gate, but only max_combined_price checks the prices you would actually pay. The two work together. In the paired quote example, the gate paired_best_bid_sum = threshold and the cancel rule's spread =" and a literal number. Two legs, one yes and one no, both action: buy, reference: best_bid, post_only: true, with equal offsets. A max_combined_price on the quote rule is allowed. One cancel_all rule whose when.all has exactly one spread condition with op: "<" and the same number. Identical guard conditions on position_size, portfolio_position_count and order_count in both rules. 5 and 5.0 count as different. The trade offs of this shape: It has no order_count == 0 gate, since adding one to the quote rule alone makes the shape unrecognized. Live, the rule therefore cancels and re sends both legs every loop. Your own quotes also narrow spread, so the cancel rule can pull them on the next loop. The maker replay keeps unchanged quotes in place and doesn't show this. The two leg prices add up to 1 − spread + 2 × offset. Wherever twice the offset reaches the live spread, the pair costs $1.00 or more; this example's 0.03 offset does that whenever the spread is exactly 0.06. The max_combined_price: 0.98 in the example makes the Bot skip those pairs, and it keeps the same value in every variant. To compare changes the grid can't express, such as different YES and NO offsets, give Deep Research explicit strategy candidates instead.3f:T2eda,Per Fill Profit Targets and Stops This page covers per fill exits in Kalshi custom strategies (platform: kalshi, strategy: custom): the four keys that let a sell_yes or sell_no rule manage each purchase at its own price, how the Bot tracks those purchases, and when it blocks trading because it can't trust them. Per fill exits can't share a strategy with composite orders. For where these rules go in your rule list and how they run in backtests, see Rule order and requirements and Per fill exits in backtests. A plain sell_yes rule sells your whole YES position when its conditions pass. Add a per fill key and it manages individual purchases instead. Each buy fill becomes a lot with its own actual price, and the rule sells a lot when that lot's own target or stop is reached. Average cost is never used. Error messages and logs call these entry relative exits or entry targets. Each exit that fires is logged under its key's name (entry_profit_offset, entry_stop_loss_offset or entry_profit_targets) with the fill's price, target and quantity. Parameter Type Default Allowed values What it does entry_profit_offset number (dollars) none Above 0, below 1 Sells a lot once the bid reaches lot price + offset, rounded up to the market's next valid price entry_stop_loss_offset number (dollars) none Above 0, below 1 Sells a lot once the bid falls to lot price − offset or lower entry_profit_targets list of rows none At least one row Gives fills at an exact price their own target price entry_profit_targets[].entry_price number (dollars) required Up to four decimals, above 0 and below 1, unique across rows The exact fill price the row applies to entry_profit_targets[].target_price number (dollars) required Up to four decimals, above entry_price, below 1; valid on the market’s price grid The minimum sale price for those fills entry_profit_min_time_to_expiry duration none (every fill eligible) A whole number plus s, m or h Uses the table only for fills made with more than this long left before close Each per fill rule: uses action: sell_yes for YES lots, judged on the YES bid, or action: sell_no for NO lots, judged on the NO bid, has no size (the quantity comes from each lot) and no orders, carries exactly one kind of exit: one offset, or one table. Put the stop and the target on separate rules, still needs a when block, usually yes_position_size 0 or no_position_size 0. The messages the validator gives for mixing these keys are in What can be combined, and those for bad values are in Common validator messages. How fills become lots The Bot records each of its own buy fills per market: the price actually paid, quantity, fees and time. Every loop, it checks that record against your Kalshi fills and holdings. Oldest first. Buying the opposite outcome nets against your oldest lots first, and so do ordinary exits such as sell_all. Start flat. The Bot never adopts contracts it didn't buy itself: only fills of this deployment's own orders become lots. Separate ownership. Additional same side contracts from manual trades or other Bots do not become this Bot's lots. New entries wait while the account holds inventory outside this Bot. If the account holds fewer contracts than its lots require, the Bot blocks new entries with "entry lots disagree with account holdings; new entries blocked, exits allowed". Exits remain capped at this Bot's available inventory and the account's holdings on that side, after pending exits are reserved. One record per deployment. The record survives an ordinary Bot restart. An in place runner rebuild restarts the Bot on an empty disk; the Bot then rebuilds each market's lots from this deployment's own fills, which it recognizes by their order ids. A rebuilt record doesn't know which lot an earlier exit was aimed at, so it closes the oldest lots first. An explicit Upgrade or Update Software in Studio instead stops all live and paper Bots on that runner and leaves a fresh, idle runner; exchange positions stay open without those Bots managing their exits. Deploying the strategy again starts a new, empty record that doesn't adopt the previous deployment's contracts, so close per fill positions before you deploy again. Settlement. When Kalshi reports the market settled (its API says finalized), the remaining lots close at the result and the market's record is done. How a per fill rule matches A per fill rule is eligible only when both are true: 1. a lot on its side qualifies: its target is reached, its stop is triggered, or a table row matches and is reached, and 2. the rule's when conditions pass. If no lot qualifies, evaluation falls through to the next rule, so an entry below can still fire that loop. When the rule fires, the Bot picks the oldest qualifying lot, skipping older lots that don't qualify. It sends one immediate or cancel, reduce only limit sell for that lot, and handles at most one lot per market per loop. Quantity is the smallest of: the lot's remaining contracts, 40, and your deployment's Max contracts per order. Because your entry orders are capped by the same Max contracts per order limit, a lot normally sells in one order. It takes several loops only if the lot is larger than 40 contracts, or if you lowered Max contracts per order after the lot was bought. A partial fill reduces only that lot. Polling, not resting. Targets and stops are checked once per loop, at the current bid. They are not orders waiting on the book, so a price that passes through between loops can be missed, and a stop can sell well below its trigger. entry_profit_offset The target for each lot is its fill price plus the offset, rounded up to the market's next valid price: the next cent, or the next 0.1¢ on markets that allow it. When that side's best bid is at or above the target, the Bot sends an immediate or cancel sell with the target as its limit. That limit is a minimum, so the sell can fill higher. A 0.38 fill with a 0.05 offset has a 0.43 target. A 0.853 fill with the same offset targets 0.903 on a market with 0.1¢ steps, or 0.91 on a whole cent market. The offset is measured before fees. A 5 cent offset is not a 5 cent net gain. If no valid market price below 1 can meet fill price plus offset, the target can never be reached. It is not lowered. For example, a 0.989 fill plus 0.01 targets 0.999 on a market with 0.1¢ steps, but has no tradable target on a whole cent market. The Bot logs a blocked decision instead, at most every 15 minutes. entry_stop_loss_offset A lot's stop triggers when that side's best bid is at or below the lot's fill price minus the offset. The comparison is exact, with no rounding. The sell is sent at the current bid rounded down to the market's valid prices, not at the trigger price. A fill at 0.85 with a 0.10 stop triggers at a bid of 0.75. If the bid gaps straight to 0.729, the Bot sends the sell at 0.729 on a market with 0.1¢ steps, or 0.72 on a whole cent market. The sale price can be well under the trigger, and the sell can fill partly or not at all. An unfilled remainder is tried again only while the stop condition still holds. A missing bid never triggers a stop, and the rounded bid must be a valid market price strictly between 0 and 1. If the market’s price steps are unavailable, targets and stops use whole cents. entry_profit_targets A table maps an exact fill price to its own target price. A lot qualifies only if its actual fill price exactly equals a row's entry_price and the bid is at or above that row's target_price. The Bot then sells it with an immediate or cancel limit at target_price, which is a minimum. Fills without a row get no table target. A buy that got price improvement (you bid 0.88 and filled at 0.85) matches the 0.85 row. In the table above, a sub cent fill such as 0.8501 matches no row; sub cent fills can match when an exact row is supplied. Pair every table with a stop rule that covers all fills. Rows use up to four decimals. Both prices must be above 0 and below 1, and each target must be above its entry price. 0.85555, 1.00 and duplicate entry prices are rejected. Use sub cent rows such as 0.995 only on markets that allow 0.1¢ steps. For sell_no, rows are NO prices. The table reads NO fills and the NO bid. The price band doesn't apply. Exit prices are not clamped by risk.price_floor or risk.price_ceiling. Targets must be on the market's price grid. If a target isn't a valid price for that market, the exit fails with "entry target is outside the supported market price grid" and the rest of that market's rules are skipped for that loop. YAML anchors work, so a YES rule and a NO rule can share one table. See one target table for YES and NO fills. entry_profit_min_time_to_expiry Restricts the table on the same rule to fills made with more than this much time left before the market closes. Eligibility is decided at the moment of the fill and never changes after, so an early fill can still take profit inside the final window. A fill whose time or market close time is unknown is not eligible. Valid values are a whole number followed by s, m or h: 90s, 15m, 2h, 48h. 1d, 1.5h, 1h30m, 0m and a bare 900 are rejected. It is only allowed on a rule that has entry_profit_targets, and it doesn't affect stops on other rules. This differs from a time_to_expiry condition, which checks the time left now. With rows 0.85 → 0.95 and 0.88 → 0.97, entry_profit_min_time_to_expiry: 30m, and a market closing at 17:00: Fill Price Filled at Time left at fill Table target A 0.85 16:10 50 min 0.95 B 0.88 16:30 30 min None: the time left must be more than 30 minutes C 0.84 16:05 55 min None: no row for 0.84 D 0.8501 16:12 48 min None: no exact match If the bid reaches 0.95 at 16:50, lot A sells even though only 10 minutes remain. B, C and D are covered by the stop rule only. The entry price profit table example pairs this kind of table and time gate with a stop rule. When per fill exits block entries When the Bot can't trust its lots, it blocks new entries in that market and logs a blocked decision, but exits keep running: Log message Cause What still runs "entry lots disagree with account holdings; new entries blocked, exits allowed" The account holds fewer contracts on a side than this Bot's lots require Exits against available Bot owned inventory, capped at account holdings, and max_loss "entry target submission awaiting confirmed order and fills" An earlier per fill exit's result is unknown (for example after a timeout), until Kalshi confirms the order and its fills Plain exits (sell_yes, sell_no, sell_all) and max_loss can use only unreserved Bot owned inventory. Per fill exits pause too, so a lot is never sold twice An unconfirmed exit clears on its own once Kalshi confirms it, and the mismatch clears once holdings match the lots again. The Studio terminal shows a mismatch as the entry_lots_mismatch guardrail. To trade that market again sooner, stop the Bot, close the position, fix the cause, and deploy again from flat. A different error, "entry target is outside the supported market price grid", appears only when an exit rule fires with a target or stop price that isn't a valid price for that market. That exit isn't sent, and the rest of that market's rules are skipped for the loop. Change the table row or offset so that targets land on the market's price grid. With risk.max_loss set, the loss ledger is built from these lots in every market the run has evaluated, not just the current one. A holdings mismatch in a market the Bot evaluates halts the run the way any max_loss attribution mismatch does: the Bot cancels its orders, sells the inventory its lots account for, and opens nothing new for the rest of the run. Start the run flat, with no resting orders, in every market it may trade. The check also re reads every market the run has evaluated, on every loop. With market.selection: all or a fast rolling series that list keeps growing, so each loop sends more requests to Kalshi and can run into its rate limits, which pause new orders.40:T13cd,Rule Level Trading Schedules This page covers rule level schedules in Kalshi custom strategies (platform: kalshi, strategy: custom): the keys, how they combine with a top level schedule, what happens to orders at window edges, overnight and overlapping windows, and the format rules. A rule level schedule can't share a strategy with composite orders or a top level active_window; see What can be combined. For a complete strategy, see Time varying EMA distance entry thresholds. A trading_schedule inside a buy_yes or buy_no rule limits when that rule may buy. It has the same shape as the top level trading_schedule (see Trading schedule). Its main use is time varying entry thresholds: write one entry rule per threshold, each with its own hours. Parameter Type Default Allowed values What it does trading_schedule (on a rule) mapping none Only on buy_yes/buy_no rules Weekly hours when this rule may enter trading_schedule.timezone string required UTC, or an IANA name such as America/New_York The timezone for this rule's windows. It is not inherited from the top level. trading_schedule.trading_hours list of windows omitted: all week 1 to 32 windows in total, counting blackouts The only windows when this rule may enter trading_schedule.blackouts list of windows none Counts toward the 32 Windows when it may not enter. Blackouts win over trading hours. trading_hours[].days list of strings required Unique mon tue wed thu fri sat sun, lowercase The days each window starts on (blackouts too) trading_hours[].start string required "00:00" to "23:59", zero padded, quoted Window start, included trading_hours[].end string required "00:00" to "24:00", different from start Window end, excluded. Earlier than start wraps past midnight. How the two schedules combine A scheduled entry rule may buy only when both the top level schedule (if you have one) and its own schedule allow the current minute. If its conditions match while either schedule is closed, the Bot logs a blocked decision (outside_trading_hours or schedule_blackout) and evaluation continues to the next rule. So you can stack entry rules with different thresholds and windows. Where windows overlap, the higher rule wins, as usual. Two more reasons can block a scheduled entry: schedule_unavailable when the schedule's timezone data can't be loaded (entries stay blocked, exits still run), and schedule_cancellation_pending while the Bot is still cancelling pending entries at a window edge or after a restart. A rule window that never overlaps the top level schedule's open hours is accepted, but that rule can never enter. Exits are never blocked by time. Stops and profit rules can't carry a rule level schedule, so they run at all hours. Orders at window edges Pending entries are cancelled at every edge. When any rule's window opens or closes, and when the Bot starts, it cancels all of its own pending entry orders. That includes orders from rules whose windows are still open. Exits and other Bots' orders stay. New entries wait until the cancel succeeds, logged as schedule_cancellation_pending. Resting entries also expire on the exchange. A resting entry gets an expiry at the next window edge, so an order placed at 10:59 expires at 11:00 even if the Bot is offline. Sells become reduce only. With any schedule in the strategy, top level or rule level, every sell is reduce only and limited to contracts this Bot bought that aren't already reserved by a resting exit. If none are left, the sell fails with "no unreserved Bot owned inventory for this exit". Rules in a scheduled strategy can't sell contracts you bought by hand. For how window edges behave in paper trading and backtests, see Backtests and paper trading. Overnight and overlapping windows When end is earlier than start, the window runs past midnight and belongs to the day it starts on. A sun window from "22:00" to "02:00" covers Sunday 22:00 to Monday 02:00. Two rules can overlap: From 22:00 to 01:00 only window_a_primary can enter. From 01:00 to 02:00 both windows are open: an ask from 0.55 to 0.75 fires window_a_primary, and an ask from 0.50 up to 0.55 falls through to window_b_fallback. From 02:00 to 03:00 only window_b_fallback can enter. A scheduled rule never makes the rules below it unreachable, so overlapping windows are fine. An unscheduled rule with the same conditions placed above a scheduled one does, and fails with "earlier rules make this rule unreachable". See Save time behavior checks. Schedule format rules Common validator messages lists the message most of these mistakes get when you save. timezone is UTC or an IANA name with a slash, such as America/Chicago. utc, GMT, EST and Etc/GMT+5 are rejected. Daylight saving time is handled for you. Quote times and zero pad them: "09:00", not 9:00. "24:00" is allowed only as an end. Omit a list you don't use. trading_hours: [] is rejected, and so is trading_schedule: {}. The windows must leave some time open: "trading hours and blackouts leave no time for entries". Only buy_yes/buy_no rules take a schedule. Anything else is rejected:41:T1b28,Advanced Kalshi Rule Examples These are complete Kalshi custom strategies (platform: kalshi, strategy: custom) that use the advanced rule keys: composite orders, per fill exits and rule level schedules. Every complete example on this page passes the same checks as a Studio save, except the last, Rejected: quotes plus per fill exits, which shows a combination the validator refuses and the error it gets. Market tickers, prices, sizes and thresholds are illustrative only. They show how the keys work, not what to trade, and they are not recommendations. Backtest and paper trade any strategy before you deploy it live. Paired YES and NO quote with a combined cap Quotes both outcomes one cent above their best bids when the pair's combined cost stays at or under $0.98. The pair rests instead of being re sent every loop. It is pulled from about 15 minutes before to 15 minutes after an FOMC or CPI release, in the last 10 minutes, and when other traders' bids push the combined best bids above 0.985. What to notice: order_count == 0 lets the pair rest and keep its queue place. The three cancel_all rules above it decide when it comes down. The quote gate reads the raw bids; max_combined_price re checks the actual leg prices after rounding and clamping. pull_when_outbid can't tell your bids from other traders', so it watches the sum, which includes your own quotes. Pulling needs other bids to push the sum above 0.985. If only one leg fills, position_size 0 stops re quoting, and the other leg rests until announcement_blackout or cancel_near_close pulls it. This strategy has no sell rule, so a lone filled leg is held until the market settles. That is legging risk; add a sell_all rule if you want a way out. risk.max_entries_per_market is left out: each leg uses an entry, so a value of 1 would block every pair. Studio prefills Max contracts per order from the largest leg (1), and Max open contracts as risk.max_position (2), which covers both legs. The validator also checks that the two legs together fit max_position. Live, the calendar values refresh every 5 minutes and don't count down in between, so the announcement pull can start and end up to 5 minutes late. Backtests compute them exactly. For a wider live margin, raise the 900 second thresholds. Backtests run in the Kalshi maker replay and need economic calendar data for the whole window. NO bid one cent under the ask, weekday sessions A single post only NO bid one cent under the NO ask, only on weekdays from 13:00 to 24:00 UTC. It exits the whole position at a profit or stop level with sell_all. What to notice: best_ask on a NO leg is the NO ask: 1 minus the best YES bid. While the bid rests one cent under the ask, the spread is exactly one cent. If the ask moves up, the spread widens, requote_when_ask_moves cancels, and the next loop bids one cent under the new ask. A top level schedule is allowed with orders. When it closes at 24:00 UTC, the Bot cancels the resting bid. Exits still run at any hour. The exits use sell_all, not sell_yes or sell_no, so the strategy backtests the same way in the maker replay. Live, sell_all doesn't cancel the resting bid. Per fill 5 cent profit and 10 cent stop Buys YES in a price band, then manages each fill on its own: sell a fill when the YES bid is 5 cents above what that fill cost, or stop it out when the bid is 10 cents below. This is the full rule order from Rule order and requirements. What to notice: Worked numbers: a 0.38 fill has a 0.43 target and a 0.28 stop trigger. A 0.42 fill has a 0.47 target and a 0.32 trigger. Each fill is managed at its own price, not the average. buy_yes places a limit at the ask. If it doesn't fill right away, cancel_unfilled_entry pulls it on the next loop, and the entry can fire again at the new ask. Each loop sells from at most one fill, capped at Max contracts per order, which Studio prefills as 1 here. Backtest with a taker backtest and a flat starting account. See Per fill exits in backtests. Entry price profit table with a time gate Buys YES between 85 and 88 cents. Each fill gets a target from the table, but only fills made more than 30 minutes before close. Every fill keeps an 8 cent stop. What to notice: A fill at a price with no row, such as 0.84 after price improvement or a sub cent 0.8501, is protected by the stop only. The 30 minute gate is judged when the fill happens. A fill at exactly 30 minutes before close is excluded. An earlier fill keeps its target through the final 30 minutes. Studio prefills Max open contracts from risk.max_position (4). A deploy with a lower Max open contracts stops the Bot below 4 contracts; a higher one still stops it at 4. Time varying EMA distance entry thresholds On weekdays, buys YES in the BTC daily series when spot BTC trades far enough above its 26 period, 5 minute EMA. How far is a strict threshold from 09:30 to 11:00 ET and a looser one from 11:00 to 16:00 ET. A short top level blackout pauses entries around 10:00 ET. Per fill exits run at all hours. What to notice: ema_26_5m_distance_pct is a fraction: 0.004 means spot is 0.4% above the EMA. See Edge Data. Each entry needs its own conditions, its own window, and the top level schedule. The 09:55 to 10:05 blackout cuts into the strict window. Every rule schedule names its own timezone; nothing is inherited from the top level. The Bot cancels pending entry orders at 09:30, 11:00 and 16:00, while the blackout is in force, and on restart. See Orders at window edges. If the Coinbase feed can't be fetched (beyond its staleness allowance), the Bot blocks new entries on that market and cancels its resting entry orders there; the stop and take profit rules keep running. If only the EMA field is unavailable, for example after a late 5 minute candle, conditions on it are false: neither entry rule fires, and the stop and take profit rules still run. yes_best_ask <= 0.85 matters: buy_yes bids at the ask, clamped to price_ceiling, so without it an ask of 0.95 would leave a resting 0.90 bid. One target table for YES and NO fills Buys whichever outcome is the 85 to 88 cent favorite, never both. Every YES and NO fill gets an 8 cent stop and one shared target table. Entries are allowed on weekdays only, through a reusable rule level schedule made of blackouts. What to notice: For NO fills, the stop and table read the NO bid and match the NO fill price. &favorite_targets and &weekdays_only are YAML anchors; favorite_targets and weekdays_only reuse them. The opposite side position checks stop a buy on one side from netting against contracts you hold on the other side. Kalshi nets YES and NO in one market, which would close your oldest lots at that price. Rejected: quotes plus per fill exits Resting composite quotes can't share a strategy with per fill exits, in any rule order and with a table or an offset (see What can be combined). Use per fill exits with buy_yes/buy_no entries, or composite quotes with sell_all/cancel_all exits.42:T2d93,Edge Data and Derived Metrics Edge data is outside information your strategy reads next to the venue's own order book: Coinbase crypto prices and indicators, National Weather Service (NWS) observations and forecasts, and the official FOMC and CPI announcement calendars. Derived metrics turn one of those values into a distance from a Kalshi market's strike, such as "BTC spot is $250 above this market's strike". Studio's AI writes this YAML for you. Use this section to check what each key means, which values are allowed, and what your Bot does when the data is late or missing. Besides this page, the section has six pages, listed below: one for declaring and reading aliases, one field catalog per provider, one for derived metrics, and one for complete examples and validation errors. This page covers what applies to every provider: how edge data fits into a strategy, where it works, what backtests support, and how freshness and fail closed behavior work. Note: Every example in this section uses small, illustrative sizes and thresholds to show the syntax. They are not recommendations, and none of them implies a strategy will make money. In this section Declaring and Reading Edge Data: The keys of an edge alias (name, provider, selector, fields, refresh) and how rule conditions read its values: units, two field comparisons, text fields and unavailable values. Coinbase Edge Fields: Every Coinbase field (prices and quotes, change windows, highs and lows, moving averages, EMA distance, VWAP, velocity and MACD), its backtest support, and when candle based fields go unavailable. NWS Weather Edge Fields: How to choose a station, every National Weather Service field (observations, daily and hourly forecasts, alerts, precipitation text), and how NWS values differ in backtests. Economic Calendar Edge Fields: The FOMC and CPI event selectors, the countdown fields and why they freeze between refreshes, and a recipe that pauses a strategy around each announcement. Sports Edge Fields: Live score, period and game clock for a Kalshi football, basketball, hockey or soccer game, read from the team's side, with the timing caveats and a recipe for in game entry cutoffs and late closeouts; plus ESPN's live win probability for NFL and NBA games, to trade a model against the Kalshi price. Derived Metrics: The derived: block and its one kind, signed_distance_from_strike: which Kalshi markets have a strike, when a metric blocks entries, backtest caveats, and a spot and EMA recipe. Edge Data Examples and Validation Errors: Six complete strategies (Coinbase change, EMA distance and MACD filters, NWS forecasts on Polymarket US and against a Kalshi strike, and an FOMC/CPI blackout) and a table of common edge validation errors. How edge data works You declare named aliases in a top level edge: block. Each alias names one provider, one selector for that provider (a Coinbase product, an NWS station or a set of calendar events), the fields your rules may read, and how often to refresh. Rules then read a value as edge. . . Every key is described in Declaring and Reading Edge Data. A separate top level derived: block (Kalshi only) declares numbers the Bot calculates from one edge field and the market's strike. Rules read them as derived. . See Derived metrics. Edge data takes effect only in strategy: custom on Kalshi and Polymarket US. See Where edge data works. For how rules, conditions and actions work in general, see Custom Rules. Where edge data works A few details the table leaves out: When data goes missing, both venues block new entries on that market while exits keep running. Kalshi also cancels the strategy's resting entry orders there; Polymarket US leaves resting orders in place. See When an alias goes missing. Built in strategies such as spread_capture or mean_reversion accept an edge: block, but never fetch it, so it has no effect and there is nothing to backtest. Regular Polymarket rejects edge: with regular Polymarket strategies do not support edge aliases. Kalshi Perps custom rules read six Coinbase MACD fields by name instead; see Kalshi Perps. Arbitrage's own net_edge_bps field is unrelated to edge data; see Arbitrage. Backtest support Historical backtests with edge data run on Kalshi only. Support depends on the provider and field: Provider Backtestable How history differs from live coinbase 35 of 39 fields. bid, ask, spread and spread_bps are live only, and a rule that reads one fails the backtest with no historical backfill for field. Rebuilt from completed Coinbase candles, sampled once per minute. Final candle values become available at the candle's close; between closes, the last available value is reused. Historical candles cannot reconstruct live forming candle signals inside a minute, and a subminute strategy loop does not add subminute Coinbase history. An alias with candles: live is backtested on the forming candle at each minute mark. See Coinbase Edge Fields. nws 38 stations: KLGA, KJFK, KEWR, KBOS, KORD, KMDW, KSFO, KOAK, KLAX, KSAN, KDEN, KPHX, KLAS, KMIA, KMCO, KATL, KIAH, KHOU, KDFW, KSEA, KPDX, KDCA, KIAD, KBWI, KPHL, KMSP, KDTW, KCLT, KSLC, KMEM, KBNA, KTPA, KTBW, KHSE, KILM, KCHS, KJAX, KMSY. Any other station stops the backtest. Rebuilt from public weather archives, not NWS itself, and several fields change meaning. See NWS in backtests. sports No. Live game state has no replayable history, so a rule that reads it fails the backtest; run it in Paper instead. Live and Paper only. espn No, for the same reason. Live and Paper only. economic_calendar Yes, when the official calendars cover the whole window. Otherwise the run fails with official economic calendar does not bracket requested window. Seconds are computed exactly at every simulated tick, so backtests never show the live refresh lag. A few rules apply to every provider: Backtests load fields referenced by rule conditions and by each derived metric's observed value. An observed field does not need an extra rule condition just to load its history. See Backtesting derived metrics. Aliases that neither a rule nor a derived metric reads are ignored, although live they are still fetched and can still block ticks. refresh is ignored. Instead, a Coinbase value older than 10 minutes or an NWS value older than 2 hours counts as unavailable. An unavailable value makes every condition false, including !=, as it does live. Single market backtests count a tick where a rule referenced edge value is unavailable as blocked, and cancel the simulated resting orders. That blocked tick runs no exits either, while a live Bot blocks only entries during an outage, so a backtest can hold a position through an outage that a live stop loss would have closed. See Backtest data for how Studio treats historical data in general. Freshness, missing data and fail closed behavior Edge data fails closed for entries: when an alias cannot be refreshed in time, the Bot opens nothing in that market rather than trading on old numbers, while exits that don't need the data keep running. A few NWS fields are exceptions and fail open. What happens each tick For a custom strategy on Kalshi or Polymarket US, each market tick runs in this order: 1. Read every alias. Each declared alias is read from its cache, fetched again if needed. This happens before any rule runs, whether or not a rule reads that alias. 2. Block entries if an alias is missing. Every field of a missing alias reads as unavailable, and the Bot logs a blocked edge_data decision. No buy rule may place an order on that market this tick: a matching one is skipped, and the rules below it still run. On Kalshi the Bot also cancels this strategy's resting entry orders on that market; its resting exit orders, such as take profits, stay. On Polymarket US nothing is cancelled. 3. Compute derived metrics (Kalshi only). If the strike or the observed value is unavailable, every derived field reads as unavailable and entries are blocked the same way. See When a derived metric blocks entries. 4. Run the rules top to bottom. A condition on an unavailable field is false, whatever the operator (see Unavailable values). The refresh cache Each alias has its own cache: A value younger than refresh is reused without fetching. An older value triggers a fetch. If the fetch fails, the last good values are reused while they are at most 3 × refresh old. Past that, the alias is missing and entries are blocked. Three consequences are easy to miss: The very first fetch has no fallback. If it fails right after the Bot starts, the alias is missing at once. A long loop leaves no stale tolerance. Once loop.interval is longer than 3 × refresh, a single failed fetch blocks that tick's entries. Failures are retried every tick. A failed fetch does not reset the refresh clock, so the Bot retries a failing provider on every tick and for every market it evaluates. Each request can wait a few seconds before timing out, so an unreachable provider can slow the whole loop. Values measured relative to the fetch, such as seconds_to_next, seconds_since_previous and observation_age_sec, stay frozen between fetches: up to one refresh normally, and up to 3 × refresh while fetches fail. When an alias goes missing A missing alias blocks new entries on that market until data returns. Exits keep running: a stop loss or take profit that reads only market data (price, the book, position_size, unrealized_pnl) fires as usual, and max_loss keeps being checked. An exit whose own condition reads the missing alias can't fire meanwhile, because that condition is false. On Kalshi the Bot also cancels the strategy's resting entry orders on that market, which keeps a maker strategy from leaving quotes on stale data; resting exit orders stay. Keep aliases to what your rules need. A failing alias that no rule reads still blocks every entry. Fields that fail open Some NWS fields fall back to a "nothing happening" value instead of becoming unavailable when a sub lookup fails: Field Reads during a lookup failure alert_active 0 (no alert) alert_severity none precip_type none precip_amount_in 0 The forecast temperatures and all precip_prob fields go unavailable instead, so conditions on them are false. Every precip_prob field also reads 0 when NWS publishes a period without a probability. Don't treat an alert flag of 0 as proof that the weather is calm. Schedules and active windows On Kalshi, aliases are fetched before trading_schedule is checked, because the schedule only blocks entries. Outside trading hours the Bot keeps fetching every loop, and an outage still cancels resting entry orders. Before active_window starts, the Bot idles and fetches nothing. After it ends, the Bot keeps fetching for the markets it still holds or has orders in, so their exits keep running; entries stay blocked either way. Checking live values in Studio On Kalshi, the Studio live terminal's Live market data panel lists each alias's fields with current values. Studio fetches those values itself on every terminal refresh, so they can differ from what your Bot evaluated on its last tick. A value that is unavailable, or a field of a failed alias, shows as a dash. The panel also fills in related Coinbase fields you did not list: any one MACD field shows all three for that timeframe, and an EMA or either of its distances shows both _distance_usd and _distance_pct. Your Bot also records the finite values of its listed edge fields, and its derived metrics, in its trading journal samples. Related pages Strategy Reference overview Kalshi and Polymarket US for market selection and risk keys Custom Rules for conditions, operators and actions Backtest data and Monitoring43:T2683,Declaring and Reading Edge Data This page is the key by key reference for the edge: block in custom strategies on Kalshi and Polymarket US: how to declare an alias, and how rule conditions read its values. For how edge data fits into a strategy, where it works and what happens when data is late, see Edge Data and Derived Metrics. The YAML examples on this page are rejected on purpose, to show the error each mistake produces. Declaring an edge alias Parameter Type Default Allowed values What it does edge map of aliases none 0 to 8 aliases Declares the outside data sources your rules can read. alias name map key none lowercase letter, then up to 31 lowercase letters, digits or _ Your label for the source; rules read edge. . . More provider string required coinbase, nws, economic_calendar, sports, espn Which data source the alias reads. More symbol string required for coinbase, sports and espn Coinbase product id such as BTC USD; for sports and espn, a Kalshi team market ticker such as KXNFLGAME 26OCT18ARILAR LAR The crypto product, or the team whose game to read. More station string required for nws 4 uppercase letters such as KMDW The NWS observation station to read. More event string required for economic_calendar FOMC, CPI, FOMC,CPI The announcements to track. More fields list of strings required names from the provider's catalog The values rules may read. More refresh duration string 5s Coinbase, 5m NWS, 15m calendar, 10s sports, 15s ESPN a duration at or above the provider minimum How long a fetched value is reused; also sets how long stale data is tolerated. More candles string left out live, closed; coinbase only Whether candle based Coinbase fields read the forming candle (live) or completed candles only (closed). More Alias names The alias is your own label. It does not pick the data: btc does not imply BTC USD, so you always declare the symbol too. Names must match ^[a z][a z0 9_]{0,31}$: start with a lowercase letter, then lowercase letters, digits or underscores, 32 characters at most. btc and nyc_temp work; BTC and bad alias are rejected. You can declare up to 8 aliases. An empty edge: {} is accepted. Declare only aliases your rules use. Live, the Bot reads every declared alias on every tick (fetching it when its refresh is due), and a failing alias blocks entries even if no rule reads it. Providers and selectors Each provider has exactly one selector key. Set that key directly on the alias, and no other selector. Provider Selector key Selector format Example Fields Minimum refresh Default refresh coinbase symbol Coinbase product id: uppercase letters or digits, one hyphen BTC USD, ETH USD 39 1s, or 5s with any candle based field 5s nws station 4 uppercase letters (an ICAO station id) KMDW, KLGA 57 60s 5m economic_calendar event FOMC, CPI or both, comma separated, no spaces FOMC,CPI 4 5m 15m sports symbol a Kalshi team market ticker: KX, then three hyphen separated parts KXNFLGAME 26OCT18ARILAR LAR 13 5s 10s espn symbol a Kalshi NFL or NBA team market ticker (KXNFLGAME or KXNBAGAME ) KXNBAGAME 26OCT22CLEPHI PHI 3 10s 15s Provider names are lowercase and exact. NWS or binance fails with unknown provider. A missing selector fails (provider "coinbase" requires selector "symbol"), and so does the wrong one (provider "nws" expects selector "station", not "symbol") or more than one (exactly one selector allowed). Only the format is checked. A product or station that does not exist, such as ZZZZ, passes validation, then every live fetch fails and every entry is blocked. Double check the id before you deploy. Selectors are case sensitive: btc usd, kmdw and fomc are rejected with does not match required format. Fields fields lists the provider values this alias exposes. It must be a non empty list of names from the provider's catalog: Coinbase, NWS, economic calendar, sports or ESPN. A name outside the catalog fails, for example provider "nws" has no field "temp_hour_13". Rules and derived metrics can read only fields listed here. Reading an unlisted one fails with edge field "..." not listed in alias "...". The list does not change what is downloaded. Each refresh fetches the provider's full data set. For Coinbase, listing any candle based field raises the minimum refresh from 1s to 5s. Listing a field does not make it backtestable. See Backtest support. Refresh refresh is how long the Bot reuses a fetched value before fetching the alias again. It also sets the stale limit: if a fetch fails, the last good values are reused until they are 3 × refresh old. After that the alias is missing and entries are blocked. See The refresh cache. Write it as a duration with a unit: 10s, 5m, 1m30s or 2.5s. Valid units are ns, us, ms, s, m and h. A bare number (5) fails with missing unit, and days (1d) fail with unknown unit "d". There is no maximum. Provider When Minimum Default coinbase every listed field is one of price, bid, ask, spread, spread_bps, change_24h, volume_24h 1s 5s coinbase any other field is listed (all of them are built from candles) 5s 5s nws always 60s 5m economic_calendar always 5m 15m sports always 5s 10s espn always 10s 15s The cache is only checked when your loop runs, so a refresh shorter than loop.interval means "fetch on every loop" and gains nothing more. Each Coinbase refresh makes six requests (stats, book and four candle sizes) whatever fields you list. Keys Studio does not check Inside an alias, keys other than provider, symbol, station, event, fields, refresh and candles are ignored without an error. A typo such as refesh: 30s silently falls back to the default refresh, and a selector: wrapper is ignored (the alias then fails for a missing selector). Check spelling carefully. If you write an alias on one line with braces, quote a two event list. In {provider: economic_calendar, event: FOMC,CPI, fields: [seconds_to_next]} the unquoted comma splits the value, so only FOMC is kept and CPI is dropped with no error. Write event: "FOMC,CPI" or use block style, as in the blackout recipe. Reading edge values in rules Parameter Type Default Allowed values What it does field (edge) field reference none edge. . with a declared alias and a listed field Reads an edge value in a condition. field (derived) field reference none derived. with a declared metric (Kalshi only) Reads a derived metric in a condition. More value number, or text for a text field none a finite, unquoted number; 0 to 1 for NWS fraction fields; one of the field's values for a text field The literal to compare with. More value_field field reference none any rule field, including edge and derived fields Compares with another field instead of a literal. More Each condition needs exactly one of value or value_field. Edge references must have exactly three parts: edge.btc or edge.btc.price.x fails with edge field must be edge. . , and an undeclared alias fails with edge alias "..." not declared. Numbers and units Every edge value except the four text fields is a plain number, and value must be one too. Fractions, not percents. Coinbase change_ and _distance_pct fields are fractions: write 0.004 for 0.4%. NWS humidity and every precip_prob field run from 0 to 1: write 0.70 for 70%. Checked ranges. A literal for NWS humidity, precip_prob, precip_prob_day_2, precip_prob_day_3, precip_prob_hour_1 to precip_prob_hour_12 or alert_active must be between 0 and 1, or the save fails with expects a fraction in [0,1] (or expects a flag in [0,1] for alert_active). No quotes. value: "100000" is rejected with requires a numeric value (got string) — remove the surrounding quotes. Calendar fields are plain seconds, so value: "30m" is rejected too; write 1800. Finite only. .inf and .nan fail with must be finite. Currency. Coinbase prices are in the product's quote currency: USD for USD pairs, USDT for USDT, BTC for ETH BTC. Field names ending in _usd also mean the quote currency. Comparing two fields value_field compares a field with another field on the same tick, for example edge.btc.macd_1m against edge.btc.macd_signal_1m, or edge.eth.change_24h against edge.btc.change_24h from a second alias. Studio does not check that both sides use the same units or timeframe. Comparing edge.btc.price (dollars) with the contract price (0 to 1), or macd_1m with macd_signal_5m, saves fine but means little. The 0 to 1 range check does not apply to value_field comparisons. There is no crossover operator. macd_1m macd_signal_1m tests the current relationship on every tick, not a one time cross. Text fields Four fields hold text rather than numbers: NWS precip_type and alert_severity, and calendar next_event_type and previous_event_type. A rule can test one for equality with a value it can take: Field Values precip_type none, rain, snow, mixed alert_severity none, advisory, watch, warning next_event_type, previous_event_type FOMC, CPI Use == or !=. Text can't be ordered, so , = fail with is a text field; use == or !=. Write one of the listed values. Quotes are optional: value: warning and value: "warning" are the same. Values are case sensitive, so Warning or fomc fails with is not one of, and a number fails with is a text field; value must be one of. No value_field. A text field can't be compared with another field, on either side. Text conditions work live and in backtests. Text has no order, so "at least a watch" has to list the values: Unavailable values A healthy alias can still hold individual values that are unavailable for a moment: a Coinbase candle is late, an NWS forecast lookup fails, a station does not report humidity. A condition that reads an unavailable value is false for every operator, including !=, live and in backtests. That holds on either side of a value_field comparison. The condition fails, so an all rule does not match, while an any rule can still match through its other conditions. Later rules still run.44:T29f8,Coinbase Edge Fields A coinbase alias reads public Coinbase Exchange market data for one product (symbol: BTC USD). All 39 fields are numbers. Prices are in the product's quote currency; changes and _pct distances are fractions. This page lists every field by group, with its unit and backtest support, then explains the candles setting and when candle based fields go unavailable. Custom strategies on Kalshi and Polymarket US read a field as edge. . once it is listed in the alias's fields. For the alias keys and refresh minimums, see Declaring and Reading Edge Data. Kalshi Perps reads the six MACD fields by name instead; see Kalshi Perps. Price and quote fields These come from Coinbase's 24 hour stats and top of book. They are the only fields that allow a 1s refresh. Field Unit Meaning Backtest price quote Last trade price. Yes (completed 1 minute close) bid quote Best bid; unavailable when that side of the book is empty. No, live only ask quote Best ask. No, live only spread quote ask minus bid. No, live only spread_bps basis points Spread divided by the midpoint, × 10,000. No, live only change_24h fraction Last price vs. the price 24 hours ago: (last − open) ÷ open. Yes (completed hourly candles) volume_24h base asset Volume traded over 24 hours, in the base asset (BTC for BTC USD). Yes (completed hourly candles) Historical backtests make each candle's final values available only after that candle closes. Between closes, they reuse the last available value. Live fields that include a forming candle can change before its close, so those intraminute signals cannot be reconstructed from historical candles. To make live and backtest values line up, see Live or closed candles. A 10 second strategy loop does not turn one minute Coinbase history into 10 second price history. Change windows Each change compares the latest close, including the candle still forming, with an earlier close. All are fractions (0.004 = +0.4%). Field Built from History needed Backtest change_5m latest 1 minute close vs. 5 candles earlier 6 one minute candles Yes (completed 1 minute candles) change_15m latest 1 minute close vs. 15 candles earlier 16 one minute candles Yes (completed 1 minute candles) change_1h latest 5 minute close vs. 12 candles earlier 13 five minute candles Yes (completed 5 minute candles) change_4h latest hourly close vs. 4 candles earlier 5 hourly candles Yes (completed hourly candles) High and low windows Highest high or lowest low over recent candles, in the quote currency, including the candle still forming. With less history, fewer candles are used. Fields Window Backtest high_15m, low_15m last 15 one minute candles Yes (completed 1 minute candles) high_1h, low_1h last 12 five minute candles Yes (completed 5 minute candles) high_4h, low_4h last 4 hourly candles Yes (completed hourly candles) high_24h, low_24h last 24 hourly candles Yes (completed hourly candles) Moving averages Averages of candle closes, in the quote currency. Field Meaning History needed Backtest sma_20_1m Simple average of the last 20 one minute closes. 20 one minute candles Yes (completed 1 minute candles) ema_12_1m 12 period exponential average of one minute closes, including the forming candle. 12 one minute candles Yes (completed 1 minute candles) sma_50_5m Simple average of the last 50 five minute closes. 50 five minute candles Yes (completed 5 minute candles) ema_26_5m 26 period exponential average of five minute closes, including the forming candle. 26 five minute candles Yes (completed 5 minute candles) ema_26_15m 26 period exponential average of completed 15 minute closes. 26 or more completed 15 minute candles, with no gaps in the last 250 (about 62 hours) Yes (completed candles only) EMA distance Each EMA has two ready made distance fields that measure how far price sits from it. Positive means spot is above the average, negative below. Field Unit Meaning ema_12_1m_distance_usd quote price − ema_12_1m ema_12_1m_distance_pct fraction (price − ema_12_1m) ÷ ema_12_1m ema_26_5m_distance_usd quote price − ema_26_5m ema_26_5m_distance_pct fraction (price − ema_26_5m) ÷ ema_26_5m ema_26_15m_distance_usd quote price − ema_26_15m ema_26_15m_distance_pct fraction (price − ema_26_15m) ÷ ema_26_15m A distance is unavailable whenever its EMA or price is. The _pct versions are handy across products, because a 0.2% band means the same on BTC and ETH, while a dollar band does not. All six are backtestable. Backtests use the latest completed one minute close as spot for every distance field, including ema_26_15m distances. To compare an EMA with a Kalshi strike rather than with spot, use the raw EMA field in a derived metric. See Recipe: spot and EMA vs. strike. VWAP and velocity Field Unit Meaning Backtest vwap_1h quote Volume weighted average of the typical price, (high + low + close) ÷ 3, over the last 12 five minute candles. Yes (completed 5 minute candles) vwap_24h quote The same over the last 24 hourly candles. Yes (completed hourly candles) velocity_1m quote per second Latest one minute close minus the previous one, divided by the seconds between them (normally 60). Yes (completed 1 minute candles) MACD MACD compares a fast and a slow exponential average of completed candle closes. Each timeframe has three fields, all in signed quote currency. Field Meaning macd_1m MACD line: 12 period EMA minus 26 period EMA of completed one minute closes. macd_signal_1m Signal line: 9 period EMA of the MACD line. macd_histogram_1m macd_1m minus macd_signal_1m. Positive when the MACD line is above its signal. macd_5m, macd_signal_5m, macd_histogram_5m The same on completed five minute closes. Each timeframe needs at least 34 completed candles (26 for the slow average plus 9 for the signal, minus the one they share), and every candle in the roughly 250 the Bot downloads must be back to back. One missing candle leaves all three fields unavailable until it is more than 250 candles old: about 4 hours for the _1m fields, about 21 hours for _5m. All six fields are backtestable and use completed candles only, in live and historical runs alike, unless the alias sets candles: live. MACD values are in the product's quote currency (dollars for USD pairs), not percent, so their size scales with the product's price. A histogram threshold that fits BTC means something very different on ETH or SOL. Live or closed candles By default, fields read candles in two different ways. MACD and ema_26_15m (with its distances) use completed candles only. Every other candle based field also reads the candle still forming on Coinbase. Backtests use completed candles for all of them. The optional candles key on a Coinbase alias makes every candle based field read candles the same way: candles Live Bot Backtest left out MACD and ema_26_15m use completed candles; the other candle based fields include Coinbase's forming candle. Completed candles for every field. live Every candle based field includes the forming candle, closed at Coinbase's last trade price. MACD and the EMAs move inside a candle, so rules can fire before it closes. The forming candle at each minute mark, closed at that minute's last trade. velocity_1m is not backtestable. closed Every candle based field uses completed candles only. Values change only when a candle closes. Completed candles for every field, so the live Bot and the backtest read the same values. price, bid, ask, spread, spread_bps, change_24h and volume_24h are not built from candles and do not change with the setting. Choose live when a signal should count before its candle closes, for example acting on a 5 minute MACD turn as it happens. The cost: Earlier signals can reverse. A MACD that turns positive halfway through a candle can turn back before the candle closes, so expect more false signals and more trades than with completed candles. A short gap at each close. Right after a candle closes, every field built from that candle size is unavailable for a few seconds, until Coinbase publishes the completed candle. Backtests read once a minute. At each minute mark the backtest rebuilds the forming 5 minute, 15 minute and hourly candles exactly from completed one minute candles. A one minute candle has only just opened at that moment, so one minute fields cannot show a signal firing inside a minute, which a live Bot can act on. The result says so: "1m live fields are read once a minute in backtests; a live Bot also sees moves inside the minute." velocity_1m would always read 0 at those moments, so a live alias that reads it cannot be backtested; backtest that strategy with candles: closed instead. Choose closed when the live Bot should behave exactly like its backtest, at the cost of reacting later. candles is only valid on a coinbase alias, and only as live or closed: Changing candles changes the Bot's code. A running Bot keeps reading candles the old way until you redeploy it. Candle history and freshness If Coinbase history preparation fails before backtest execution, the run stops without a completed result and does not retry automatically. Choose Retry history preparation to retry the same strategy later; if it keeps failing, contact support with the job ID. This is a history preparation failure, so the card does not offer Fix with AI to change the strategy's rules. For live Bots, there is no warm up wait. On every refresh the Bot downloads about the last 250 candles of each size (1 minute, 5 minutes, 15 minutes, 1 hour), so indicators have values from the first fetch after you deploy. A field is unavailable only when: Coinbase's history is too short, for example a newly listed product. The history has gaps. Coinbase omits candles for intervals with no trades, which is common on thin products. MACD and ema_26_15m need every downloaded candle to be back to back, so a single gap leaves them unavailable for hours (see MACD). The latest candle is late or missing. If the most recently completed candle is not in Coinbase's data within 10 seconds of its close, every field built from that candle size is unavailable for that refresh. Coinbase publishes no candle for an interval with no trades, so on thin products a quiet minute has the same effect as a late candle. The alias itself stays healthy. Candle size Fields built from it 1 minute change_5m, change_15m, high_15m, low_15m, sma_20_1m, ema_12_1m and its distances, velocity_1m, the three _1m MACD fields 5 minutes change_1h, high_1h, low_1h, sma_50_5m, ema_26_5m and its distances, vwap_1h, the three _5m MACD fields 15 minutes ema_26_15m and its distances (completed candles only, unless candles: live) 1 hour change_4h, high_4h, low_4h, high_24h, low_24h, vwap_24h none price, bid, ask, spread, spread_bps, change_24h, volume_24h45:T1768,NWS Weather Edge Fields An nws alias reads the US National Weather Service for one observation station: its latest observation, the daily and hourly forecasts for its location, and active alerts for its county. There are 57 fields: 55 numbers and 2 text fields that rules compare with == or != (see Text fields). This page covers how to choose a station, every field by group, and how NWS values differ in backtests. Custom strategies on Kalshi and Polymarket US read a field as edge. . once it is listed in the alias's fields. For the alias keys and refresh minimums, see Declaring and Reading Edge Data. Choosing a station station is a 4 letter ICAO id in capitals, such as KMDW (Chicago Midway) or KLGA (LaGuardia). Only the format is checked, so confirm the id exists before you deploy. Pick the station your market settles on. For example, Kalshi's New York daily high markets settle on Central Park (KNYC), not LaGuardia. Only 38 stations can be backtested, listed under Backtest support. KNYC and KAUS are not among them. If the station's observation or its location lookup fails, the whole alias fails. If only a forecast or alert lookup fails, the alias stays healthy and the affected fields degrade (see Fields that fail open). Observation fields From the station's latest report. Field Unit Meaning current_temp_f °F Latest observed temperature. humidity fraction 0 to 1 Relative humidity. Write 0.70 for 70%. wind_speed_mph mph Observed wind speed. wind_direction_deg degrees Observed wind direction. pressure_mb millibars Observed barometric pressure. dew_point_f °F Observed dew point. observation_age_sec seconds Age of the observation when it was fetched. It stays frozen between fetches. observation_age_sec is a simple staleness guard: a condition such as observation_age_sec < 5400 ignores reports that were more than 90 minutes old when fetched. Because the value is frozen between fetches, allow for up to one refresh of extra age. Daily forecast fields NWS forecasts come in daytime and nighttime periods, not calendar days. forecast_high_f is the first daytime period, so once today's daytime period has passed, it describes tomorrow. Field Unit Meaning forecast_high_f °F First daytime period's temperature. forecast_low_f °F First nighttime period's temperature. precip_prob fraction 0 to 1 First daytime period's chance of precipitation. A missing value reads 0. temp_delta_from_forecast_high_f °F current_temp_f − forecast_high_f. Negative while still below the forecast high. forecast_high_day_2_f, forecast_low_day_2_f °F Second daytime and nighttime periods. precip_prob_day_2 fraction 0 to 1 Second daytime period's chance of precipitation. A missing value reads 0. forecast_high_day_3_f, forecast_low_day_3_f °F Third daytime and nighttime periods. precip_prob_day_3 fraction 0 to 1 Third daytime period's chance of precipitation. A missing value reads 0. precip_amount_in inches Amount parsed from the forecast text. Not recommended; see Precipitation text fields. precip_type text rain, snow, mixed or none. Compare with == or !=; see Text fields. Not recommended; see Precipitation text fields. Local time forecast_high_f means forecast_low_f means forecast_high_day_2_f means 10:00 today tonight tomorrow 20:00 tomorrow tonight the day after tomorrow Hourly forecast fields Twelve hourly periods, each with three fields, 36 fields in total. N runs from 1 to 12; temp_hour_0 and temp_hour_13 do not exist. Fields Unit Meaning temp_hour_1 … temp_hour_12 °F Forecast temperature for the Nth hourly period. precip_prob_hour_1 … precip_prob_hour_12 fraction 0 to 1 Chance of precipitation for the Nth period. A missing value reads 0. wind_hour_1 … wind_hour_12 mph Forecast wind for the Nth period. For a range such as "10 to 15 mph" it takes the low end. The first period is normally the hour in progress, so temp_hour_1 is about now and temp_hour_6 about five hours ahead. Alert fields Field Unit Meaning alert_active 0 or 1 1 when any NWS alert is active for the station's county, including advisories and special statements. alert_severity text Highest active alert: none, advisory, watch or warning. Compare with == or !=; see Text fields. alert_active fires on minor alerts too: a heat advisory counts. If the alert lookup fails, it reads 0, not unavailable, so an alert based exit does not fire during that outage. Precipitation text fields Two fields are read from the wording of the first daytime forecast rather than from a number. Neither works as a dependable filter: precip_type is matched on keywords: "rain" or "showers" means rain, "snow" means snow, both mean mixed. "Snow showers likely" therefore reads mixed, while drizzle, sleet, flurries or thunderstorms alone read none. precip_amount_in recognizes only two phrasings and reads 0 for everything else, including "less than a tenth of an inch" and "around an inch". It can also pick up an unrelated measurement, such as snow depth or hail size. A value of 0 does not mean "no rain expected". For rain risk, use precip_prob or the precip_prob_hour_N fields. NWS in backtests NWS history is rebuilt from public weather archives (Open Meteo reanalysis and forecasts, and the Iowa Environmental Mesonet warning archive), so several fields mean something slightly different in a backtest: Observations are modeled values at the station's coordinates, not the station's own report. pressure_mb is sea level pressure. Daily forecasts use the day's max, min and max chance of precipitation for the sample's UTC date, not NWS periods. They exist only for roughly the last 92 days; older samples are unavailable. Hourly forecasts use the hour containing sample time + N hours, about one hour later than the live field with the same N. Like the daily forecasts, they exist only for roughly the last 92 days. precip_amount_in and precip_type are observed precipitation, not forecast text. Alerts cover the station's whole forecast office and count warnings, watches and advisories only.46:Tc28,Economic Calendar Edge Fields An economic_calendar alias tracks official US macro announcement times. It has no prices; it tells your rules how far you are from the next and previous announcement. This page covers the event selector, the four calendar fields and how their countdown behaves between refreshes, and a recipe that pauses a strategy around each announcement. Custom strategies on Kalshi and Polymarket US read a field as edge. . once it is listed in the alias's fields. For the alias keys and refresh minimums, see Declaring and Reading Edge Data. Calendar events event value Tracks FOMC Federal Reserve FOMC meetings, from the Fed's calendar page. Each announcement is taken as 14:00 New York time on the meeting's last day. CPI Consumer Price Index releases, from the Bureau of Labor Statistics release schedule, at the scheduled time (normally 08:30 New York time). FOMC,CPI Both, merged: next and previous are taken across both lists. Order does not matter, and a repeated token such as CPI,CPI counts once. Write the tokens in capitals with no spaces, directly on the alias. Other events (such as NFP), lowercase and spaces fail with does not match required format. Nesting the event under selector: fails with requires event directly on the edge alias. The alias fails, and ticks are skipped, if a selected calendar cannot be fetched or lists no announcements, or if the selected announcements together have none before or none after the current time (see When an alias goes missing). With FOMC,CPI, if one calendar has not yet published its next date, seconds_to_next counts to the other calendar's next announcement instead, with no error. Unscheduled meetings, or changes not yet on the official pages, are unknown to the Bot. Calendar fields Field Unit Meaning Backtest seconds_to_next seconds Time until the next selected announcement. Never negative. Yes, exact seconds_since_previous seconds Time since the most recent selected announcement. Never negative. Yes, exact next_event_type text FOMC or CPI. Compare with == or !=; see Text fields. Yes, exact previous_event_type text FOMC or CPI. Compare with == or !=. Yes, exact Both seconds are measured when the alias is fetched and do not count down between refreshes. With the default 15m refresh, seconds_to_next can overstate the real time left by up to 900 seconds, plus up to one loop.interval, because a new fetch happens only when your loop runs. While fetches are failing, the last snapshot is reused for up to 3 × refresh (2,700 seconds at 15m); see The refresh cache. Neither value is ever negative, so a condition such as seconds_to_next The "after" side needs no margin: the pre release snapshot keeps the "before" condition true until the first fetch after the release. A calendar outage long enough to drop the alias blocks every entry. On Kalshi that also cancels resting entry orders, which acts like a blackout for quotes. On Polymarket US resting orders stay in place. The 30 minute window is illustrative, not a recommendation. For a complete strategy built around a blackout, see Pausing quotes around FOMC and CPI.47:T1a31,Derived Metrics A derived metric is a number the Bot calculates from one edge value and the current Kalshi market. There are two kinds: signed_distance_from_strike, the observed value minus the market's strike, and minus_yes_ask, a win probability minus the market's YES ask (see Model minus the YES ask). Rules read either as derived. . Derived metrics work only in strategy: custom on Kalshi, and each one reads an edge alias declared in the same strategy (see Declaring and Reading Edge Data). This page covers the derived: keys, which markets have a strike, when a metric blocks entries, backtesting, and a recipe that compares both spot and an EMA with the strike. For edge data in general, start at Edge Data and Derived Metrics. Declaring a derived metric Parameter Type Default Allowed values What it does derived map of metrics none 0 to 8 metrics; Kalshi strategy: custom only Declares numbers calculated from an edge value and the market's strike. metric name map key none same rule as alias names; only kind and observed inside The name rules read as derived. . kind string required signed_distance_from_strike or minus_yes_ask Observed value minus the market's strike (More), or minus the market's YES ask (More). observed field reference required edge. . : a declared alias and a listed numeric field The value the strike is subtracted from. Any other key, such as strike:, offset: or adjustment:, fails with unsupported derived metric key. The strike always comes from the market, and there is no arithmetic beyond the subtraction. observed must be an edge field: built in fields such as price fail with must be edge. . . Text fields fail with must reference a numeric edge field. Any numeric edge field is accepted, including raw EMAs. Fields unrelated to a strike, such as seconds_to_next, also pass validation, but the result is meaningless. On Polymarket, Polymarket US or a Kalshi built in strategy, derived: fails with derived metrics are supported only for custom Kalshi strategies. Kalshi Perps and arbitrage reject it as an unknown top level key. Which markets have a strike The strike comes from the Kalshi market's own strike type, and only one sided markets have one: greater, greater_than, greater_or_equal ("above X" markets) use the market's floor strike. less, less_than, less_or_equal ("X or below" markets) use its cap strike. The sign does not flip: a positive distance still means the observed value is above the cap, which is the losing side for YES. Range buckets and every other type have no strike. Their entries are blocked with strike_unavailable. The literal strike is used, with no bucket or settlement adjustment. On a whole degree "greater than 85°F" market the strike is 85, so the temperature has to reach 86, a distance of +1, to be above it. Rules cannot read the strike itself, only the distance through derived. : a strike or market.strike field fails with unknown field. To test the observed value alone, use the edge field directly. If your series mixes "above" and "or below" markets and your rules assume positive means YES is winning, filter the "or below" markets out, for example with a yes_best_ask floor as in the recipe at the end of this page and the forecast high example. When a rule that reads a derived field fires, its decision log entry records the observed value, the strike, the distance and whether the value was above, below or at the strike. When a derived metric blocks entries Every declared metric is computed on every tick, after the market is read. If any one fails, every derived field reads as unavailable and entries on that market are blocked for the tick: the strategy's resting entry orders there are cancelled, and exit rules that don't read a derived field still run: strike_unavailable: a signed_distance_from_strike metric is declared and the market has no usable one sided strike, such as a range bucket. A strategy with only minus_yes_ask metrics never needs a strike. derived_input_unavailable: the observed value is unavailable, for example a late or missing Coinbase candle behind an EMA, an NWS forecast outage, or ESPN publishing no win probability yet; or, for minus_yes_ask, the market has no YES ask. With market.series_ticker and selection: all, the range markets in a series are simply never traded. With the default selection only the most liquid market is evaluated, and if that is a range market every entry is blocked, so series that mix range and threshold markets usually need selection: all. If you pin a single market with market.ticker, a deploy can be rejected up front with selected Kalshi market does not expose a supported numeric strike. Model minus the YES ask minus_yes_ask subtracts the market's best YES ask from a probability, so a rule can buy only when a model rates the team well above what Kalshi charges. Its observed value must be a field of an espn alias (team_win_prob, opponent_win_prob or tie_prob); any other provider fails with minus_yes_ask must observe an espn win probability field. With team_win_prob at 0.62 and the YES ask at 0.50, derived.model_edge is 0.12. It is a difference in probability, so 0.08 means 8 points. There is no strike, so a team market deploys without the strike check. Rules that fire on it record no strike evidence in the decision log. ESPN aliases cannot be backtested, so neither can this kind. Backtesting derived metrics Derived metrics work in Kalshi backtests, subject to history and strike availability: Observed fields are loaded automatically. Backtests include each metric's observed edge field even when no rule condition reads that field directly. You do not need a duplicate condition to load its history. The field must still support historical backfill, and missing or stale history can still make the metric unavailable. Mixed series can fail. Remote derived data backtests capture a supported strike for every candidate market during history preparation. A missing or unsupported strike stops preparation instead of silently dropping that market; execution uses the captured strikes without fetching fresh market metadata. Other backtest modes may block range markets tick by tick or stop the whole run with strike unavailable. Recipe: spot and EMA vs. strike To ask "is the trend, not just the last trade, above this market's strike?", point a second metric at a raw EMA field. Use the EMA itself (ema_26_5m), not one of its _distance fields, which measure distance from spot. Sizes and thresholds in this recipe are illustrative, not recommendations. If the 5 minute candle behind ema_26_5m is late, derived_input_unavailable blocks entries until it arrives, and the exit, which reads the same distance, can't fire meanwhile.48:T1db6,Edge Data Examples and Validation Errors This page collects complete custom strategies for Kalshi and Polymarket US that read edge data and derived metrics, followed by the validation errors Studio shows for the most common mistakes. For what each key and field means, start at Edge Data and Derived Metrics. Example strategies Each example compiles as written. Sizes, thresholds and market choices are illustrative only. Before you deploy anything, backtest it where the venue allows and review its limits on Risk & Limits. BTC 15 minute markets with a Coinbase change filter Buys YES on Kalshi's 15 minute BTC markets after a short up move on Coinbase, and exits if the last five minutes turn down. Both change fields include the one minute candle still forming. If a candle is late, both are unavailable and neither the entry nor the exit fires on that tick (see Candle history and freshness). EMA distance band Buys YES on Kalshi's daily ETH markets when spot is above its one hour VWAP and within 0 to 0.4% above the 15 minute EMA 26. Exits if spot falls 0.2% below that EMA or the contract price reaches 0.75. Without selection: all, only the most liquid market of the current event is traded. In backtests, vwap_1h and change_1h come from five minute candles the samples can see up to 5 minutes early. MACD line vs. signal line Trades both sides of Kalshi's 15 minute BTC markets on one minute MACD momentum. It buys YES when the MACD line is above its signal, velocity is positive and spot is above the 5 minute SMA 50, and buys NO on the mirror image setup. Each side exits when the histogram turns against it. The entries compare the MACD line with its signal through value_field, and the exits test the histogram's sign, which is the same relationship. If the latest one minute candle is late, or any one minute candle in roughly the last four hours is missing, all three MACD fields are unavailable, so neither the entries nor the MACD exits fire on those ticks. NWS forecast on Polymarket US Buys NO on an illustrative Polymarket US "NYC high 80°F or above" market while the LaGuardia forecast high and the forecast for the sixth hourly period (about five hours ahead, temp_hour_6) stay well below 80. Polymarket US has no derived metrics, so the thresholds are written as plain temperatures. Check your market's resolution rules for its settlement station; KLGA is used here only to show the syntax. price is the market's YES price. In the evening, forecast_high_f already describes tomorrow, so check that your market's date matches (see Daily forecast fields). If the NWS alias goes missing, Polymarket US skips ticks but keeps resting orders. This strategy cannot be backtested. Forecast high vs. strike with an alert exit On Kalshi's Chicago daily high markets, buys YES when the NWS forecast high at Chicago Midway is at least 3°F above that market's strike and rain odds are under 40%. Exits on any active NWS alert or when the forecast margin shrinks below 1°F. The yes_best_ask floor matters here: on the series' "or below" market a positive distance means YES is losing. If the NWS forecast lookup fails, forecast_high_f is unavailable, so the derived metric blocks entries and the exits that read it can't fire until it returns (see When a derived metric blocks entries). If the alert lookup fails, alert_active reads 0. KMDW can be backtested, but forecast history covers only about the last 92 days. Pausing quotes around FOMC and CPI Rests a paired YES and NO quote one cent above each best bid while the combined bids leave room under $0.98, and pulls the strategy's resting orders on that market from about 35 minutes before until 30 minutes after any FOMC or CPI announcement. order_count == 0 lets the pair rest instead of being cancelled and re sent every loop. Your own quotes are part of the book, so the pull rule watches paired_best_bid_sum rather than spread. If only one leg fills, position_size 0 stops re quoting and the other leg keeps resting until it fills or the blackout pulls it. The strategy has no sell rule, so a filled contract is held until the market settles. The blackout sits first so it wins over the quoting rules. With a 5 minute refresh it starts roughly 35 to 30 minutes before the release, depending on when the last fetch happened (see Blackout recipe). During a calendar outage it can start as late as about 20 minutes before, and once the alias goes missing entries are blocked and the resting quotes cancelled. For multi order rules like quote_pair and the max_combined_price cap, see Composite Orders and max_combined_price in Advanced Kalshi Rules. Common validation errors Each row pairs text from an error message with its usual cause. Declaring and Reading Edge Data and Derived Metrics explain each rule in context. Message contains Cause at most 8 edge aliases allowed More than 8 aliases. alias name ... must match Uppercase letters, hyphens or a leading digit in an alias name. unknown provider Provider misspelled or not lowercase. requires selector Coinbase alias without symbol, or NWS alias without station. requires event directly on the edge alias Calendar alias without event, or event nested under selector:. expects selector The wrong selector key for the provider. exactly one selector allowed More than one of symbol, station and event. does not match required format Lowercase or malformed selector, a space in FOMC, CPI, or an unsupported event. fields must be non empty Missing or empty fields list. has no field A field name outside the provider's catalog. invalid refresh duration A refresh with no unit or with days. below provider minimum A refresh under the provider's minimum. edge field must be edge. . A reference without exactly three parts. not declared A rule reads an alias or derived metric that isn't declared. not listed in alias A rule or observed reads a field missing from the alias's fields. exactly one of value or value_field must be set A condition with both value and value_field, or with neither. requires a numeric value (got string) A quoted number, or a duration like "30m", on a numeric field. is a text field; use == or != , = on a text field. is a text field; value must be one of A number compared with a text field. is not one of A text value the field never takes, often a capitalization difference such as Rain. must be finite .inf or .nan as a value. expects a fraction in [0,1] A percent written as a whole number on an NWS fraction field. expects a flag in [0,1] An alert_active value outside 0 to 1. value_field cannot be used with text edge fields value_field with a text field on either side. regular Polymarket strategies do not support edge aliases An edge: block on platform: polymarket. unknown top level field An edge: or derived: block on Kalshi Perps or arbitrage. derived metrics are supported only for custom Kalshi strategies derived: on Polymarket, Polymarket US or a built in strategy. at most 8 derived metrics allowed More than 8 derived metrics. derived metric name ... must match Uppercase letters, hyphens or a leading digit in a derived metric name. .observed: required A derived metric without observed. unsupported derived metric kind A kind other than signed_distance_from_strike. unsupported derived metric key A key other than kind or observed in a metric. must reference a numeric edge field observed points at a text field. unknown field A rule field that does not exist, such as market.strike (rules cannot read the strike). selected Kalshi market does not expose a supported numeric strike At deploy: a pinned market.ticker with no one sided strike.49:T4eee,Kalshi Perps Strategy Reference This section covers platform: kalshi_perps: strategies that trade Kalshi's perpetual futures on crypto assets. It lists every key a Kalshi Perps strategy accepts, what each one does when your Bot runs, and the caveats that matter once real money is involved. Event contract strategies on Kalshi use a different format; see Kalshi. The reference is split across this page and the pages listed under In this section. This page has the overview: how perps differ from event contracts, a minimal strategy, the full parameter table with a link from every key to its details, the top level keys and format rules, what the Bot does on every tick, paper trading, and deploying a Perps Bot. Studio's AI writes the strategy for you as a short YAML document. Studio checks it every time it is saved and again when you deploy, so a strategy with an invalid setting is refused before it can trade. You don't have to write YAML yourself, but reading it is the best way to confirm the strategy does what you asked. Some mistakes still get through. Misspelled keys inside a block are ignored rather than rejected (see Unknown and misspelled keys), and a few settings save fine but only fail once the Bot runs, such as a leverage above the market's cap or a ticker Kalshi doesn't list. All values in the examples in this section are illustrative. They show how the settings work, not what to trade, how much to commit or which thresholds to use. Nothing here is a recommendation or a claim about results. Leverage magnifies losses as well as gains. In this section Kalshi Perps Markets and Execution: The markets list and its perp tickers, the loop.interval cadence, and execution: taker vs limit entries, slippage, limit offset and time limit, and what happens when a close doesn't go through. Kalshi Perps Sizing and Risk: Margin and leverage sizing, the Bot's own take profit and stop loss and their limits, and funding awareness. Kalshi Perps Archetypes: The trend_rider, breakout_hunter and dip_reverter archetypes: the rules for params, the ATR stop, and what each archetype does with every parameter. Kalshi Perps Custom Strategies: Custom rules: indicators, the fields rules can read (including Coinbase MACD), operators and crossovers, actions and size_pct, missing data, setups, evaluation order, and patterns for rules that behave. Kalshi Perps Example Strategies: Seven complete strategies that save as written: one trend_rider archetype and six custom strategies using crossovers, setups, add and trim, resting entries and Coinbase MACD. How perps strategies differ from event contracts A perpetual ("perp") follows the price of a crypto asset and never expires. That changes almost everything about how a strategy is written. Event contracts (Kalshi, Polymarket) Kalshi Perps What you hold YES or NO contracts A signed position: long (positive) or short (negative) Price $0 to $1, read as a probability Dollars per contract, where a contract is a fixed fraction of a coin Size Contracts per order margin_usd × leverage of notional per entry End of a position Settles at $0 or $1 when the event resolves No expiry or settlement. Open until something closes it or the exchange liquidates it Holding cost None Funding payments between longs and shorts Exits Your rules and risk keys Your rules, plus take profit and stop loss the Bot enforces itself Backtesting Available for supported Kalshi strategies Not available. Paper trading only What this means in practice: Signed positions. Your Bot is long, short or flat, counted in contracts. position is this Bot's own position, built from its own fills. It is not your whole account's position, which your other Perps Bots and your manual trades share. Dollar prices per contract. One KXBTCPERP contract is 0.0001 BTC, so it trades near $6.45 when BTC is near $64,500. Every price field, and every price you write in a rule, is in dollars per contract. Leverage. Each entry commits margin_usd and multiplies it by leverage to get its notional size (see Sizing and Risk). All your Perps Bots trade one cross margined account, and Kalshi liquidates across that whole account. No settlement. A position stays open until a rule closes it, the Bot's own take profit or stop loss closes it, you close it, or it is liquidated. While it is open it pays or receives funding. The Bot enforces its own exits. Take profit and stop loss are not orders resting at the exchange. The Bot checks them on every tick (the check it runs every loop.interval seconds), so they stop protecting you while the Bot is stopped. See Limits of Bot enforced exits. A document of its own. There is no market, edge, trading_schedule or orders. Actions are open_long, open_short, add, reduce and close. Custom perps rules also have crossover operators and setups, which other venues don't. A minimal Kalshi Perps strategy Every 60 seconds (the default), the Bot checks KXBTCPERP. With its default settings, trend_rider compares a 9 candle and a 21 candle exponential moving average of hourly candles. It holds a long while the fast average is above the slow one and a short while it is below. Each entry commits $10 × 1 = $10 of notional, which is 1 contract at about $6.45. The Bot closes the position if the price moves 3% against its average entry. Everything left out takes its default: loop checks every 60 seconds, execution uses immediate (taker) entries with a 0.5% slippage bound, params uses the archetype's defaults, there is no take profit, and funding_awareness is off. All Kalshi Perps parameters This is the complete list. At the top level, any other key is rejected. Inside a block, any other key is ignored without an error, except in archetype params (see Unknown and misspelled keys). Percentages are plain numbers: 2 means 2%. Prices are dollars per contract. Parameter Type Default Allowed values What it does version integer required 1 Format version of the document. platform string required kalshi_perps Selects the Kalshi Perps format. strategy string required trend_rider, breakout_hunter, dip_reverter, custom A ready made archetype, or your own rules. strategy_name string none any text (Studio keeps 80 characters) Display name. No effect on trading. strategy_name_origin string generated when a name is set user, generated, curated (others saved as generated) Where the name came from. No effect on trading. markets list required 1 to 5 entries The perp markets this strategy trades, each checked separately. [markets[].ticker](/docs/strategy reference/kalshi perps/markets and execution#marketsticker) string required capitals like KXBTCPERP; no duplicates One perpetual market. loop map {interval: 60} only interval Holds the check cadence. loop.interval integer (seconds) 60 whole number ≥ 10 Pause between checks. execution map taker entries the four keys below How entries are placed. execution.entry_mode string taker taker, limit Immediate entries, or resting limit entries with a time limit. execution.max_slippage_pct number (%) 0.5 above 0, up to 5 (both modes) Furthest a taker order may be priced past the top of the book. Every exit uses it. execution.limit_offset_pct number (%) 0.05 limit mode: 0 to 5 How far behind the best price a resting entry sits. execution.limit_ttl_seconds integer (seconds) 300 limit mode: 30 to 86400 How long a resting entry waits before the Bot cancels it. sizing map required margin_usd and leverage Notional per entry. sizing.margin_usd number ($) required ≥ 1 Margin committed per entry and per add. sizing.leverage number required above 0, up to 50 (dip_reverter: up to 2) Multiplies margin into notional. The market's own cap applies when the Bot runs. risk map none (no exits) the two keys below The Bot's own percent exits. risk.take_profit_pct number (% of price) none (off) above 0 Close the whole position after this favorable move from the average entry. risk.stop_loss_pct number (% of price) none (off); required for dip_reverter above 0, below 100 Close the whole position after this adverse move from the average entry. funding_awareness boolean false true, false Skip entries on the side that currently pays funding, and let rules read the funding estimate. candles string closed closed, live (live on custom only) Whether indicators and MACD fields also read the candle still forming. indicators list none custom only; no fixed maximum Indicators your rules read by name. [indicators[].name](/docs/strategy reference/kalshi perps/custom strategies#indicators) string required lowercase letters, digits and _, starting with a letter, up to 31 characters The field name rules use. [indicators[].kind](/docs/strategy reference/kalshi perps/custom strategies#indicator kinds) string required sma, ema, rsi, atr, bollinger_upper, bollinger_lower, donchian_high, donchian_low What to compute. [indicators[].window](/docs/strategy reference/kalshi perps/custom strategies#indicators) integer (candles) required 2 to 400 Look back length. [indicators[].timeframe](/docs/strategy reference/kalshi perps/custom strategies#indicators) string required 1m, 1h, 4h, 1d Candle size. params map {} (all defaults) the chosen archetype's keys Tunes an archetype. Ignored on custom. params.timeframe string 1h 1m, 1h, 4h, 1d Candle size for any archetype. params.fast_window integer 9 ≥ 1, below slow_window trend_rider: fast moving average length. params.slow_window integer 21 ≥ 1 trend_rider: slow moving average length. params.ma_kind string ema ema, sma trend_rider: exponential or simple averages. params.mode string long_short long_short, long_only, short_only trend_rider: which sides it trades. params.confirm_closes integer 1 ≥ 1 trend_rider: agreeing closed candles needed before an entry. params.atr_stop_multiple number trend_rider: 0 (off); breakout_hunter: 2.0 trend_rider: ≥ 0; breakout_hunter: above 0 Places a fixed stop this many ATRs from the average entry price. params.atr_window integer 14 ≥ 1 ATR look back for the ATR stop or dip_reverter's volatility pause. params.entry_window integer 20 ≥ 1 breakout_hunter: channel length for entries. params.exit_window integer 10 ≥ 1 breakout_hunter: channel length for exits. params.midline_filter boolean true any breakout_hunter: has no effect today. params.rsi_window integer 14 ≥ 1 dip_reverter: RSI look back. params.rsi_oversold number 30 above 0, below 100, below rsi_overbought dip_reverter: RSI level for long entries. params.rsi_overbought number 70 above 0, below 100 dip_reverter: RSI level for short entries. params.bb_window integer 20 ≥ 1 dip_reverter: Bollinger band look back. params.bb_mult number 2.0 above 0, up to 5 dip_reverter: band width in standard deviations. params.vol_pause_mult number 1.5 ≥ 1 dip_reverter: pause entries while volatility has jumped this much. rules list none custom: at least 1; no fixed maximum Condition and action pairs, checked top to bottom. The first match acts. [rules[].name](/docs/strategy reference/kalshi perps/custom strategies#rules) string required 1 to 64 letters, digits, spaces, _ or , starting with a letter or digit Label shown in logs and decisions. [rules[].when.all / rules[].when.any](/docs/strategy reference/kalshi perps/custom strategies#rules) list of conditions one required; write only one (if both, any is ignored) 1 or more conditions Every condition (all) or at least one (any). [rules[].when.[].field](/docs/strategy reference/kalshi perps/custom strategies#fields rules can read) string required a base field, a MACD field, an indicator name or a setup name The live value on the left. [rules[].when.[].op](/docs/strategy reference/kalshi perps/custom strategies#operators and crossovers) string required = : unknown param for , including a key that belongs to a different archetype. Warning: Check key names against the parameter table. A misspelled risk or execution key saves without an error. A missing stop loss gets a deploy warning only when sizing.leverage is above 1, and even then the deploy goes ahead. Whole numbers and other format rules Whole number keys drop fractions. version, loop.interval, execution.limit_ttl_seconds, indicators[].window and setups[].expires_after_seconds are cut down to a whole number before they are checked. interval: 60.5 runs as 60, and interval: 9.9 becomes 9 and is rejected. Archetype windows must be whole. In params, 9.0 works but 9.5 fails with must be a positive integer. Zero means default. 0 is replaced by the default for loop.interval, max_slippage_pct, limit_offset_pct, limit_ttl_seconds (limit mode) and a reduce rule's size_pct. Blocks are mappings. loop: 60 and execution: taker fail to parse. Write loop: {interval: 60} and execution: {entry_mode: taker}. Each markets entry is a mapping too ( ticker: KXBTCPERP), not a bare string. One document. Anything after a line is ignored, and saving through Studio removes it. Syntax. Duplicate keys and tab indentation fail to parse. JSON works. YAML anchors and aliases work, but a top level 1. The Bot cancels its resting entries whose limit_ttl_seconds has passed. 2. It updates its own position from its fills. 3. For each market, in list order: 1. It reads the market and account state: prices, its position, P&L, your available balance, the exchange's liquidation estimate and, when funding_awareness is on, the funding estimate. 2. It runs its own exits: take profit, then stop loss, then the archetype ATR stop, which an archetype first places if its open position has none. If one of them sends a close, the strategy is skipped for that market on this tick. 3. Otherwise it runs the strategy: the archetype's logic, or your custom rules in evaluation order. If anything fails for one market, such as a failed request to Kalshi, the Bot skips only that market for this tick and goes on to the next. 4. It waits loop.interval seconds and starts again. Note: Crossover history and setups live only while the Bot runs: a stop, restart, redeploy or update clears them. The Bot's position and its ATR stops carry over. The position is rebuilt from the Bot's own fills, and each ATR stop is saved with it. Backtesting and paper trading Historical backtesting is not available for Kalshi Perps. Studio marks every perps strategy as unsupported for backtests. To see a strategy run before committing real money, deploy it as a paper Bot, and see Backtesting for the venues that support it. A paper Bot reads live Kalshi market data and simulates your account. Its fills and costs differ from live trading: Taker orders fill completely at the top of the book when it is within the order's limit. Resting orders fill only when the price trades through them. Fees are assumed at 5 basis points of notional for taker fills and 1 for maker fills. Funding is charged every hour at the live estimate. Kalshi itself settles funding a few times a day. Nothing is liquidated, and liquidation_price is always missing. Leverage below 1 is treated as 1 for margin. The starting balance is the one you choose. If you don't choose one, it is your live perps balance when Studio could read it during the deploy, or $1,000 otherwise. Deploying and running a Perps Bot Before you deploy Perps uses the same RSA or Ed25519 Kalshi credentials as event market Bots. Before reusing a runner for a live Perps deployment or update, Studio verifies the shared Kalshi credentials, even when they were previously saved. Missing credentials prompt you to reconnect; failed or unavailable verification blocks authorization until you retry. Queued deployments make the same check when claimed. The check uses the Kalshi event account balance endpoint, so it does not prove that the separate perps balance is funded, the Bot started or an order filled. Fund the perps balance. Perps Bots use your Kalshi API key but trade a separate perpetuals balance, which you fund in the Kalshi app. When you deploy with new credentials and that balance is $0, Studio warns you that the Bot can't trade until it is funded. Leverage without a stop. Studio warns when sizing.leverage is above 1 and risk.stop_loss_pct isn't set. Both are warnings: the deploy goes ahead. Deployment risk limits Perps Bots read only some of your Studio deployment risk limits: Limit What it does on a Perps Bot Max dollars per order Skips an entry whose size is above it. Size here is contracts × the order's limit price, which for a taker entry includes the max_slippage_pct bound. Studio pre fills it with margin_usd × leverage plus that bound, rounded up to whole dollars: $51 for $25 × 2 at 0.5%. When the running Bot's limits can be verified, the dialog starts from those limits instead. If readback is missing or unverified, review the suggested limits before confirming an update; see deployment risk settings. If you raise margin_usd or leverage, check this limit too or entries can be skipped. Closes are never blocked. API error limit and Error window minutes Once that many API errors happen within the window, pauses new entries and adds for one more window, with halted: API error breaker tripped ..., then resumes on its own. The deploy dialog starts at 3 errors in 5 minutes. Closes are still attempted. The deploy dialog shows only these two for Perps. Max contracts per order, Max open contracts, Max daily notional traded and Max daily loss are not read by Perps Bots. Your strategy's sizing and risk are its size controls. Perps Bots also space their order attempts at least 1 second apart. An entry skipped by this pacing tries again on the next tick if its signal or comparison still holds; a crossover entry doesn't. Closes aren't paced, but each close restarts the 1 second wait. See markets for how this affects several markets on one tick. Note: Failed requests to Kalshi count toward the API error limit, including rejected orders, but failed funding estimates don't. A tripped limit clears after one error window without a restart. Stops, restarts and updates Stopping a Perps Bot cancels its own resting orders and leaves its positions open. From then on no take profit, stop loss or rule protects them, so close them in the Kalshi app if you don't want to hold them. Restarting, redeploying or updating keeps the Bot's position, rebuilt from its own fills, and its ATR stops, which are saved with it. The clean stop beforehand cancels its resting orders. It clears crossover memory and setups, and the first reading after the restart never counts as a crossover. An in place runner rebuild also clears the Bot's saved position, so on restart the Bot first rebuilds its position from its own orders and fills on Kalshi, holding entries and exits until it has (the log shows holding: rebuilding this Bot's Position), and then places its ATR stop again from the rebuilt average entry. Upgrade or Update Software in Studio stops every live and paper Bot on that runner and provisions a fresh, idle runner with credentials preserved. It does not close exchange positions or restart their protection. Redeploy the Bots you want to run; Perps Bots then rebuild their positions as above. See Upgrading a runner. Stop all on your Kalshi Bots also stops your Perps Bots, but its optional sale covers Kalshi event contract positions only. Perps positions stay open; close them in the Kalshi app. See Run. Removing a market with Update Bot while the Bot holds a position there leaves that position unmanaged. Close it first. Several Bots, one account All your Perps Bots trade the primary cross margined account (subaccount 0). When checking how much the account can close, the Bot sums all primary account position rows for each market, so a duplicate flat row does not hide an open position. Positions in other subaccounts do not count toward that reducible size, and liquidation_price reads only primary account estimates. Each Bot still tracks its own position from its own fills, and its take profit, stop loss and rules close only that position, limited to what the primary account still holds. available_balance and liquidation_price belong to the account, not to any one Bot, and liquidation applies across the whole account: one Bot's losses can liquidate what the others hold. Watch margin across all your Perps Bots together; see Monitoring and Risk.4a:T26c7,Kalshi Perps Markets and Execution This page covers three blocks of a Kalshi Perps strategy (platform: kalshi_perps): markets, the perpetual markets the Bot trades; loop, how often it checks them; and execution, how it places entries and bounds exits. A tick is one of those checks; see What happens on every tick for its order, and All Kalshi Perps parameters for every key in one table. Markets and loop markets One to five markets, with no ticker listed twice. Each market is checked separately on every tick, in list order, with its own position, take profit and stop loss, crossover memory and setups. Sizing applies to each market: with three markets, up to three positions can be open at once, each at least one entry of margin_usd × leverage (more if your rules add), all on one shared margin account. Three things to know: A failing market doesn't hold up the rest. If anything goes wrong while the Bot handles a market, such as a failed account request, only that market is skipped for the tick: the markets after it still get their exit checks and strategy. A ticker that looks right but that Kalshi doesn't list fails on every tick with unknown perps market, and the other markets keep running. Entries on several markets in one tick can be paced. The Bot waits at least 1 second between order attempts, and a close restarts that wait too (see Deployment risk limits). If a second market wants to enter on the same tick, its entry can be skipped; a comparison based entry tries again on the next tick, but a crossover entry waits for the next crossover. Close a position before removing its market. If you remove a market with Update Bot while the Bot holds a position there, the Bot stops tracking that position. No take profit, stop loss or rule will ever close it, and the Bot's status line lists it under dropped_markets. markets[].ticker A Kalshi perpetual ticker: KX, then capital letters or digits, then PERP, such as KXBTCPERP. Lowercase fails with ticker must look like KXBTCPERP. Studio checks only the shape. It doesn't check that Kalshi lists the market. These are the markets Kalshi listed when this page was checked in July 2026. Kalshi can add or remove markets, so ask Studio to search perps markets for the current list, prices and leverage caps. Ticker Asset Coinbase MACD fields KXBTCPERP Bitcoin Yes (BTC USD) KXETHPERP Ether Yes (ETH USD) KXSOLPERP Solana Yes (SOL USD) KXXRPPERP XRP Yes (XRP USD) KXDOGEPERP Dogecoin Yes (DOGE USD) KXSUIPERP Sui Yes (SUI USD) KXZECPERP Zcash Yes (ZEC USD) KXBCHPERP Bitcoin Cash Yes (BCH USD) KXLTCPERP Litecoin Yes (LTC USD) KXLINKPERP Chainlink Yes (LINK USD) KXNEARPERP NEAR Yes (NEAR USD) KXHYPEPERP Hyperliquid No KXKSHIBPERP Shiba Inu, per 1,000 No KXADAPERP (Cardano, ADA USD) also supports MACD fields if Kalshi lists it. See Coinbase MACD fields. While it runs, the Bot reads each market's price, bid and ask, tick size, whether fractional contracts are allowed, and the current leverage cap from Kalshi's market list. loop.interval Seconds the Bot waits between ticks. The default is 60, which also applies when loop is left out or set to 0. The minimum is 10, and there is no maximum. The real period is the interval plus the time the tick itself takes. loop has no other key. The interval sets how often the Bot cancels expired resting entries, checks take profit, stop loss and the ATR stop, and runs the strategy. Keep in mind: Candle signals change once per candle. An indicator on 1h candles moves once an hour. A shorter interval mostly means exits and new candle closes are noticed sooner. Prices refresh at most once a minute. mark_price, bid and ask come from Kalshi's market list, which the Bot re reads at most every 60 seconds. With an interval under 60, those prices, and the take profit and stop loss checks that use them, don't change on every tick. Coinbase MACD is fresher. The MACD fields are refreshed every few seconds, so a shorter interval notices a 1m MACD crossover sooner. Setups. loop.interval is also the shortest allowed [setups[].expires_after_seconds](/docs/strategy reference/kalshi perps/custom strategies#setups and setup rules). Execution execution controls how the Bot places entries: open_long, open_short, add and archetype entries. Leave it out for immediate (taker) entries with a 0.5% slippage bound. Every exit, in either mode, is an immediate reduce only order bounded by max_slippage_pct. That covers take profit, stop loss, the ATR stop, close, reduce and archetype exits. execution.entry_mode taker (default): an immediate or cancel limit order priced through the book, up to max_slippage_pct past the best price. It fills right away at the best prices available up to that limit, and anything unfilled is cancelled. Kalshi Perps has no true market order. limit: a resting order placed limit_offset_pct behind the best price: below the bid for a long, above the ask for a short. The Bot cancels it on the first tick after limit_ttl_seconds. While it rests, the Bot places no other entry on that market. The value is case sensitive: LIMIT fails with must be taker or limit. A misspelled key such as entry_mod: limit is ignored, and the Bot runs in taker mode. Note: A market never has more than one of the Bot's resting entries. An unfilled entry doesn't change the Bot's position, so while one rests, a new entry or add on that market is skipped with resting entry still working; a comparison based entry tries again on the next tick, and a crossover entry waits for the next crossover. Before every limit entry the Bot asks Kalshi for its resting orders, so an entry that filled, or that you cancelled in the Kalshi app, stops blocking at once. If Kalshi can't be asked, the entry is skipped with could not check for a resting entry. execution.max_slippage_pct How far past the best price a taker order may be priced, in percent. A taker buy is a limit at ask × (1 + x ÷ 100), rounded down to the price tick. A taker sell is a limit at bid × (1 − x ÷ 100), rounded up. With a $6.4484 ask and the default 0.5, a taker buy is priced at $6.4806 or better. Default 0.5, also used when it is 0. Checked in both modes: it must be above 0 and at most 5. In limit mode it doesn't touch entries, but every exit still uses it, so a negative value (which would price every close away from the book) or one past Kalshi's price limits (which would get every close rejected) is refused when you save. The bid and ask it starts from can be up to 60 seconds old. If Kalshi reports no best price and no mark for the market, a taker order (a taker entry or any exit) is skipped with no price or zero size. execution.limit_offset_pct How far behind the best price a resting entry sits, in percent. Checked only in limit mode, where it must be 0 to 5. A long rests at bid × (1 − x ÷ 100), rounded down to the price tick. A short rests at ask × (1 + x ÷ 100), rounded up. With a $6.4473 bid, a $6.4484 ask and an offset of 0.1, a long rests at $6.4408 and a short at $6.4549. With the default 0.05, they rest at $6.4440 and $6.4517. 0 is replaced by the default 0.05, so an offset of exactly zero can't be expressed. The number of contracts is worked out from the ask (long) or bid (short), not from the resting price. A long rests behind the bid and a short behind the ask. If that side of the book is empty, the entry is skipped with no top of book for limit. execution.limit_ttl_seconds How long a resting entry may wait, in seconds. Checked only in limit mode, where it must be 30 to 86400. It defaults to 300 when left out or set to 0. The Bot cancels an expired order at the start of the next tick, so an order's real lifetime rounds up to the loop cadence. A clean stop, including the one before a redeploy or update, cancels the Bot's resting orders. Positions stay open. If the Bot stops without a clean shutdown, such as a crash, its resting orders stay on the book. When it starts again it takes them back and gives each a fresh time limit of this length. If Kalshi can't be reached at that moment, the Bot takes them back the next time it checks before a limit entry. It is how long an unfilled entry waits before it is replaced. The next entry on that market goes out only after this one fills, expires or is cancelled, so with limit_ttl_seconds equal to loop.interval an unfilled entry is re priced on every tick, and with a longer one it keeps its price for longer. When a close doesn't go through Exits are immediate or cancel, so they can fail to fill. What happens next depends on the exit and on why it failed: Accepted but not filled. Take profit, stop loss, the ATR stop and close rules written as state comparisons try again on the next tick while their condition still holds. Rejected by Kalshi, for example a price outside Kalshi's allowed range. The Bot then stops attempting whole position closes on that market, including take profit, stop loss, the ATR stop, close rules and archetype exits, until your account's position in that market changes. The log shows reduce_only close rejected by the venue. Network errors and Kalshi server errors are not treated this way; they retry on the next tick. Your account no longer holds this Bot's side, because you or another Bot closed it. The close is skipped with shared account carries no reducible size for this Bot until the account's position changes. Closes are always limited to what the shared account can actually reduce. Your account holds less than one contract of this Bot's side. The close is skipped with reducible size rounds to zero contracts, and stays skipped on that market until the account's position there changes. Close the remainder yourself in the Kalshi app if needed. Warning: While Kalshi keeps rejecting a close, the Bot retries it only every 5 minutes, and each rejection counts toward your API error limit. If you see reduce_only close rejected by the venue, check the position and close it yourself if needed.4b:T1760,Kalshi Perps Sizing and Risk This page covers how a Kalshi Perps strategy (platform: kalshi_perps) sizes its entries and limits its risk: the sizing block (margin and leverage), the risk block (the Bot's own take profit and stop loss), and funding_awareness. They apply to archetypes and custom strategies alike; see All Kalshi Perps parameters for every key in one table. Leverage magnifies losses as well as gains. Sizing sizing is required. It sets how much each entry commits: margin_usd × leverage = notional per entry, turned into whole contracts at the current price. The same amount applies to every entry and every add, on every market in markets. There is no per market sizing, and no sizing by contract count or by share of your balance. Leaving the block out, or leaving it empty, fails with two errors: sizing.margin_usd: must be at least 1 and sizing.leverage: must be in (0, 50]. Unknown keys such as max_notional or contracts are ignored. sizing.margin_usd Dollars of margin per entry, at least 1, with no maximum. Contracts = the notional ÷ the price, rounded down. The price is the ask for a long and the bid for a short (the mark if those are missing). Contracts are whole numbers unless Kalshi allows fractional trading on that market, in which case they are rounded down to 0.01. Too small to trade. If the result is below one contract, the entry is skipped with margin x leverage below one contract. $5 × 1 against a $6.45 contract is 0 contracts. Adds repeat it. Every add, and every open_long while already long, commits the same amount again. No balance check first. The Bot doesn't compare the size with your available balance before it sends the order. If Kalshi rejects it, the rejection counts toward your API error limit. sizing.leverage The multiplier that turns margin into notional. Above 0 and at most 50, with fractions such as 1.5 allowed. dip_reverter allows at most 2. Sizing only. Kalshi perp orders carry no leverage setting. Your account is cross margined, and Kalshi sets margin and liquidation for the account as a whole. The Bot also uses leverage to estimate its own margin_used. The market's cap applies when the Bot runs. Before every entry and add, the Bot compares leverage with the market's current leverage cap. If it is higher, the entry is skipped with leverage exceeds market cap. At launch the caps were about 6x for BTC, 4.5x for ETH and 2x to 3.7x for most other markets. A leverage above the cap saves and deploys, then never enters. Deploy warning. Studio warns when leverage is above 1 and there is no stop_loss_pct. It is a warning only. Take profit and stop loss risk holds the Bot's own percent exits. Leave it out and the Bot has no take profit or stop loss (dip_reverter requires a stop loss). Archetype exits and the ATR stop are separate and still run. Only these two keys exist: there is no exit at a fixed price, no dollar take profit, no trailing stop and no maximum loss key. Both are measured as a price move from the average entry, not as a return on margin. On every tick, before the strategy runs, the Bot works out the move: (mark − average entry) ÷ average entry × 100, with the sign flipped for a short. Take profit is checked first, then stop loss. Either one closes the Bot's whole position with an immediate reduce only order, and the strategy is skipped for that market on that tick. The log shows the close as take profit % or stop loss %, with the move measured on that tick. risk.take_profit_pct Close the whole position once the price has moved this percent in your favor from the average entry. Must be above 0 when set; unset means no take profit. The average entry moves when the Bot adds, so the target moves with it. At leverage L, the gain on margin is roughly L × this percent before fees, slippage and funding. At 2x, a 6% take profit is about 12% of margin. An archetype or a state based custom entry can open a new position on the next tick if its signal still holds. risk.stop_loss_pct Close the whole position once the price has moved this percent against you from the average entry. Must be above 0 and below 100 when set; unset means no stop loss. It is required for dip_reverter. The loss on margin is roughly leverage × this percent. At 2x, a 3% stop is about 6% of margin, before fees, slippage and funding. It is checked after take profit, on every tick, against the mark price. Limits of Bot enforced exits They only work while the Bot runs. Stopping, crashing or restarting leaves the position unprotected until the Bot is back. They aren't a guaranteed maximum loss. The slippage bound, price gaps between ticks, fees and funding all add to the loss. Liquidation can come first. Kalshi liquidates across your whole account. At high leverage, or with losses elsewhere in the account, a liquidation can happen before the stop price is reached. The Bot does not close positions to avoid liquidation. The mark can be up to a minute old. See loop.interval. Funding awareness funding_awareness: true makes the Bot fetch Kalshi's funding rate estimate for each market on every tick. It defaults to false. Write true or false, without quotes: "true" in quotes fails to parse. Entry veto. Any entry or add on the side that would currently pay funding is skipped with funding aware veto. A long is skipped while the estimate is above 0 (longs pay), and a short while it is below 0. An estimate of exactly 0, or one that isn't available, never blocks an entry. Entries only. Open positions are never closed or resized because of funding. Custom rules. Rules can read funding_rate_estimate only when this is true, so reading the estimate always turns the veto on too. Failures don't halt trading. If a funding request fails, the estimate is unavailable for that tick. The failure doesn't count toward your API error limit. Kalshi settles funding a few times a day (three times a day when this page was written). A crossover entry that is vetoed on its crossing tick doesn't retry.4c:T2486,Kalshi Perps Archetypes This page covers the Kalshi Perps archetypes (platform: kalshi_perps): the rules for params, the ATR stop two of them place, and what each archetype does with every parameter. The other blocks (markets, loop, execution, sizing, risk and funding_awareness) work as described in Markets and Execution and Sizing and Risk, and All Kalshi Perps parameters lists every key in one table. Values in the examples are illustrative, not recommendations. An archetype is a ready made strategy you tune with params. Choose one with strategy: trend_rider, breakout_hunter or dip_reverter. All three work on closed candles of the market's own perp price, at the params.timeframe you choose. Rules for params Only the archetype's own keys. Any other key fails with params. : unknown param for , including a key from another archetype, such as midline_filter on trend_rider. Every key is optional. A missing key takes the default in the archetype's table below. Don't write a key as null; that is rejected. Leave it out instead. Numbers. Windows must be whole numbers of at least 1. timeframe must be a string: 1m, 1h, 4h or 1d. There is no 5m or 15m. 4h candles are built by the Bot from 1h candles, in 4 hour blocks starting at 00:00 UTC. Pair checks need both keys. fast_window below slow_window and rsi_oversold below rsi_overbought are only checked when you write both keys. fast_window: 30 on its own, against the default slow_window of 21, saves and turns the strategy upside down. The ATR stop trend_rider (when atr_stop_multiple is above 0) and breakout_hunter (always) guard every position they open with a stop. It sits atr_stop_multiple × ATR(atr_window) below the Bot's average entry price for a long, or above it for a short, with ATR (average true range) measured on the archetype's candles in dollars per contract. For example, a long with a $6.40 average entry, an ATR of $0.05 and a multiple of 2 gets a stop at $6.30. The Bot places the stop on the first tick it holds a position without one, usually the tick after the entry fills (a resting entry can fill between ticks), and before take profit and stop loss are checked. The log shows ATR stop armed @ . From then on the Bot checks it on every tick, after take profit and stop loss, and closes the whole position if the mark reaches it. The log shows soft stop @ . How it behaves: It doesn't trail. It stays where it was placed. It lasts as long as the position. It is removed only once the Bot's position reads flat, never when a close is merely sent. If an immediate or cancel close fills nothing, the stop stays and fires again on the next tick while the mark is still past it. It survives restarts. The stop is saved with the Bot's position, so a stop, restart (including one caused by a Turbine software update), redeploy or update keeps it where it was. In paper trading, for a position opened before stops were saved, and after a runner upgrade that clears the saved position, the Bot places it again after the restart, from the average entry and the ATR at that moment. An update keeps it. Changing atr_stop_multiple or atr_window with Update Bot doesn't move the stop of a position that is already open. Turning the stop off (trend_rider with atr_stop_multiple: 0) removes it. It needs candle history. An archetype doesn't enter until there are more than atr_window closed candles for the ATR. If the ATR still can't be measured for an open position, the log shows ATR stop not armed yet and the Bot tries again on every tick. Tip: risk.stop_loss_pct makes a good backstop alongside it: it is measured from the average entry on every tick and needs no candles. trend_rider Moving average trend following. On each tick it computes a signal from the latest closed candle: +1 when the fast average is above the slow one, −1 when below, 0 when equal. Then: Signal Bot is long Bot is flat Bot is short +1 (fast above slow) Hold Open long Close now, open long on a later tick −1 (fast below slow) Close now, open short on a later tick Open short Hold 0 (flat) Close Nothing Close long_only treats −1 as 0, so it closes longs and never shorts. short_only is the mirror image. Param Default Allowed What it does fast_window 9 whole number ≥ 1, below slow_window Fast average length, in candles. slow_window 21 whole number ≥ 1 Slow average length, in candles. timeframe 1h 1m, 1h, 4h, 1d Candle size. ma_kind ema ema, sma Exponential or simple averages, used for both. mode long_short long_short, long_only, short_only Which sides it trades. confirm_closes 1 whole number ≥ 1 Closed candles that must all agree before an entry. atr_stop_multiple 0 (off) ≥ 0 ATR stop distance. 0 turns it off. atr_window 14 whole number ≥ 1 ATR look back for the stop. No fresh crossover needed. It enters whenever it is flat and the signal holds. After a take profit or stop loss it can open again on the next tick. confirm_closes delays entries, not exits. With 2 or more, an entry waits for that many agreeing closes, but a single disagreeing close makes the signal 0, and 0 closes the position (signal flat). Warm up. Until enough closed candles exist for both averages, the Bot logs warming indicators and does nothing. With the ATR stop on, entries also wait for more than atr_window closed candles, logging entry waits: ATR( ) for the stop is warming; exits don't wait. Log lines. A reversal closes with flip to long or flip to short; a 0 signal closes with signal flat. Each market is sized on its own: about $50 of notional per entry on each of the two, rounded down to whole contracts. After an entry fills, the Bot places its ATR stop on the next tick and keeps it, across restarts, until the position is closed. breakout_hunter Channel breakouts. When flat, it goes long when the latest closed candle closes above the highest high of the entry_window candles before it, and short when it closes below their lowest low. A long closes when a closed candle ends below the lowest low of the previous exit_window candles; a short closes above their highest high (exit channel breach). It never adds to a position, and the ATR stop is always on. Param Default Allowed What it does entry_window 20 whole number ≥ 1 Channel length for entries, in candles. exit_window 10 whole number ≥ 1 Channel length for exits, in candles. timeframe 1h 1m, 1h, 4h, 1d Candle size. atr_stop_multiple 2.0 above 0 ATR stop distance. It can't be turned off. atr_window 14 whole number ≥ 1 ATR look back for the stop. midline_filter true any Has no effect today. Signals use closed candles. Entries and exits compare the last closed candle's close, not the live mark. The signal is re checked on every tick, so after a stop out the same breakout candle can trigger a new entry while it is still the latest one. Warm up. It waits for the largest of entry_window, exit_window and atr_window, plus 2, closed candles, so it never opens a position before its exit channel and its ATR stop can work. midline_filter changes nothing. It is meant to keep only breakouts on the trend side of the channel's midpoint, but a close above the channel high is always above the midpoint (and a close below the low is always below it), so it never changes a decision. You can leave it out. Entries rest on the book, one at a time. Because limit_ttl_seconds equals loop.interval, an unfilled entry is cancelled on the next tick and, if the breakout still holds, replaced at the current price. The channel exit, the ATR stop and the stop loss are still immediate orders bounded by max_slippage_pct. dip_reverter Mean reversion. When flat, it goes long when RSI is below rsi_oversold and the last close is below the lower Bollinger band. It goes short when RSI is above rsi_overbought and the close is above the upper band. It closes a long once a close reaches the middle band (the moving average) and a short once a close falls to it (middle band target). It has fixed guardrails that other strategies don't: risk.stop_loss_pct is required. sizing.leverage is capped at 2. It enters once per position: adds are refused. It pauses new entries while volatility has jumped: if ATR now is more than vol_pause_mult × the ATR measured atr_window candles earlier, it skips entries and logs paused: volatility regime. Exits keep working. Param Default Allowed What it does rsi_window 14 whole number ≥ 1 RSI look back, in candles. rsi_oversold 30 above 0, below 100, below rsi_overbought RSI level under which a long is allowed. rsi_overbought 70 above 0, below 100 RSI level over which a short is allowed. bb_window 20 whole number ≥ 1 Bollinger band look back. bb_mult 2.0 above 0, up to 5 Band width in standard deviations. timeframe 1h 1m, 1h, 4h, 1d Candle size. vol_pause_mult 1.5 ≥ 1 How much ATR must jump to pause entries. atr_window 14 whole number ≥ 1 ATR look back, and how many candles back the earlier ATR is taken. RSI is for entries only. Exits use the middle band, plus your stop loss. The pause compares with an earlier ATR, not with a long run average. It also needs at least 2 × atr_window + 1 closed candles of history; with less, entries are not paused. A long needs RSI(14) under 25 and the last hourly close under the lower band; a short is the mirror image. funding_awareness only blocks new entries on the paying side. It never closes a position that is paying funding.4d:T4546,Kalshi Perps Custom Strategies This page covers custom Kalshi Perps strategies (platform: kalshi_perps with strategy: custom): the indicators, fields, operators, actions and setups your rules use, and the order the Bot checks them in. For every key in one table, see All Kalshi Perps parameters, and for complete strategies built this way, see Kalshi Perps Example Strategies. strategy: custom runs your own logic, built from four parts: indicators: values computed from the market's candles, read by name. rules: condition and action pairs. At least one is required. setups: optional named flags that remember an event between ticks. setup_rules: optional rules that only turn setups on and off. These four keys are rejected on archetypes, and params is ignored on custom. Custom strategies can also act before a candle closes with candles: live. The envelope (markets, loop, execution, sizing, risk, funding_awareness) works exactly as described in Markets and Execution and Sizing and Risk, and take profit and stop loss are checked before your rules on every tick. indicators Each indicator becomes a field your rules can read by its name, on either side of a condition: name: 1 to 31 lowercase letters, digits and underscores, starting with a letter. Names must be unique and can't reuse a base field such as mark_price. kind: see Indicator kinds. window: 2 to 400 candles. timeframe: 1m, 1h, 4h or 1d. 4h candles are built from 1h candles in 4 hour blocks starting at 00:00 UTC. There is no 5m timeframe for indicators; 5 minute data exists only through the MACD fields. How they behave: Perp prices, closed candles. Indicators read the perp contract's own price in dollars per contract, not the spot asset, and only closed candles. A value changes once per candle close, unless you set candles: live. When a candle has no traded close, the Bot uses the mid of its bid and ask close instead. Recomputed every tick for every market. Each indicator is one candle request per market per tick, so many indicators on several markets at a short interval add up. Warm up. sma, ema and Bollinger kinds need at least window closed candles; rsi, atr and Donchian kinds need window + 1. Until then the value is missing and rules that read it don't fire. A window longer than the market's candle history never produces a value. Perps were listed in mid 2026, so long 1d windows may not have enough history yet. Slightly different from charting tools. EMA, RSI and ATR are seeded from the candles the Bot fetches (about three windows' worth), so they can differ a little from charts that use longer history. Note: Don't give an indicator the name of a MACD field (such as macd_1m) or one of exchange_position, account_unrealized_pnl or account_margin_used. Studio accepts these names, but your indicator then silently replaces the MACD value or an internal value; an indicator named exchange_position changes how much a close or reduce rule can sell. Indicator kinds Kind Value Units sma Average of the last window closes. $ per contract ema Exponential average, weight 2 ÷ (window + 1), seeded with a simple average. $ per contract rsi Wilder RSI. 100 when there were no losses. 0 to 100 atr Wilder average true range. $ per contract bollinger_upper Simple average + 2 standard deviations of the last window closes. $ per contract bollinger_lower Simple average − 2 standard deviations. $ per contract donchian_high Highest high of the window candles before the latest closed candle. $ per contract donchian_low Lowest low of the window candles before the latest closed candle. $ per contract The Bollinger width is fixed at 2 standard deviations in custom strategies. For a middle band, add an sma with the same window. (dip_reverter's bb_mult changes the width only in that archetype.) Donchian values leave out the latest closed candle so a breakout can be compared against them. Custom rules have no candle close field, so compare mark_price (the live price) with donchian_high or donchian_low. rules Rules are checked top to bottom on each tick, for each market. The first rule whose conditions hold runs its action, applies its arm and clear, and ends that market's tick, even when the action turns out to do nothing. name: 1 to 64 letters, digits, spaces, underscores or hyphens, starting with a letter or digit. Quotes and other punctuation are rejected. Names may repeat. A close rule's name appears in the log as the close reason. when: write one of all (every condition must hold) or any (at least one), with at least one condition. Writing both is accepted, but only all is used: any is silently ignored and not even checked, so a typo inside it won't be caught. Write only one. Each condition has a field, an op, and either value (a number) or value_field (another field), never both. value must be a plain number: "0" in quotes fails with value must be a number. Don't use the YAML values .nan or .inf; they pass the save check but make the rule fail with an error when it runs, which skips the rest of that tick. action and size_pct: see Actions and size_pct. arm and clear: see Setups and setup rules. Write numbers in the field's own units: dollars per contract for prices, contracts for position, dollars for P&L, margin and balance, 0 to 100 for RSI, USD per coin for MACD, and 1 or 0 for setups. Fields rules can read Rules can read the 11 base fields below, the Coinbase MACD fields, your indicator names and your setup names. Field What it is Missing when mark_price Kalshi's current price for the perp, in $ per contract. Refreshed at most once a minute. Never (0 if Kalshi sends none) bid Best bid, in $ per contract, from the same market list. Never (0 if there is no bid) ask Best ask, in $ per contract. Never (0 if there is no ask) spread ask − bid, in $, when both exist; otherwise 0. Never position This Bot's own signed position in contracts: positive long, negative short, 0 flat. Built from its own fills and kept across restarts. Not your account's position. Never avg_entry Weighted average entry price of the Bot's open position, in $ per contract. Moves when the Bot adds, not on partial closes. 0 when flat. Never unrealized_pnl (mark_price − avg_entry) × position, in $, for this Bot only. Excludes fees and funding. 0 when flat. Never margin_used The Bot's own estimate: \ position\ × avg_entry ÷ sizing.leverage, in $. Not Kalshi's margin figure. Never liquidation_price Kalshi's estimated liquidation price for the primary account's position in this market (subaccount 0), in $ per contract. No primary account estimate for the market, and always in paper trading available_balance Your perps account's available balance, in $. Shared by every Perps Bot and your manual trading. 0 if Kalshi's response has no readable figure. Never funding_rate_estimate Kalshi's current funding rate estimate for the market. Positive means longs pay shorts. Needs funding_awareness: true. The funding request failed position, avg_entry, unrealized_pnl and margin_used describe only this Bot. In paper trading they describe the paper account, which only this Bot trades. Setups read as 1 (armed) or 0. Compare them with ==. Coinbase MACD fields Six more fields read MACD from Coinbase spot candles of the market's underlying coin, not from the perp's own price. They work only on markets with a Coinbase product in the markets table. Field What it is macd_1m EMA(12) − EMA(26) of completed 1 minute Coinbase closes, in USD per coin. macd_signal_1m EMA(9) of macd_1m. macd_histogram_1m macd_1m − macd_signal_1m. macd_5m The same on 5 minute Coinbase candles. macd_signal_5m EMA(9) of macd_5m. macd_histogram_5m macd_5m − macd_signal_5m. Comparing with a number works for any MACD field: macd_histogram_5m 0, or macd_histogram_1m crosses_above 0 (the same moment MACD crosses its signal line). Comparing with another field works only as a MACD line against its own signal line on the same interval, in either order: macd_1m with macd_signal_1m, or macd_5m with macd_signal_5m. Anything else is rejected, including histogram against signal, 1m against 5m, and MACD against mark_price or an indicator. Units are per coin. A threshold that is meaningful on BTC USD means something very different on XRP USD, so rescale thresholds for each asset. When MACD is missing. The fields are missing, and rules that read them don't fire, while fewer than 34 completed candles have been fetched, while the newest candle is more than 10 seconds late, or while the data is more than 15 seconds old. They are also missing while any candle is absent from the last 250: Coinbase leaves out candles for minutes with no trades, and one gap keeps the 1m fields missing for about 250 minutes, or the 5m fields for about 21 hours. If the Coinbase feed is unavailable on a tick, every MACD field is missing on that tick and the log says Coinbase data is unavailable and MACD rules cannot fire. Take profit and stop loss keep working during these gaps. KXHYPEPERP and KXKSHIBPERP have no matching Coinbase product, so any strategy whose rules read MACD is rejected on them with ... has no supported Coinbase product. Live candles By default (candles: closed), indicators and MACD fields read closed candles only. A value changes once per candle, so a crossover in the middle of a candle is seen only after that candle closes: up to a minute late on 1m candles, up to an hour on 1h. Set candles: live to also read the candle still forming: The forming candle closes at the live price. Indicators use the perp's mark price, refreshed on every tick. MACD fields use the last trade on the Coinbase spot product. The forming candle's high and low are the highest and lowest marks the Bot has seen since it opened, so atr starts over after a restart. Donchian values leave out the forming candle instead of the latest closed one. Values move within the candle. A comparison such as ema_fast ema_slow can be true, then false, then true again before the candle closes. A crossover counts once per candle. After a crossover between candle based fields, a reversal in that same candle isn't a crossover; if the reversal still holds on the next candle, it counts then. When the two sides use different candle sizes, the shorter one applies. Crossovers against mark_price and other live fields work as before. Briefly missing after each close. Until the venue publishes the candle that just closed, usually a few seconds, the values are missing and rules that read them don't fire. Earlier, but noisier. Acting before the close catches moves sooner, but a cross can reverse before the candle closes, so expect more entries, more fees and more false signals, especially on 1m. A loop.interval of 10 to 15 seconds gets the most out of it. Custom only. Archetypes always use closed candles, and candles: live on one is rejected with live candles are only available for custom strategies. A change takes effect when you redeploy the Bot. Operators and crossovers Comparisons ( , =, Touching isn't crossing. Equal values don't count as either side. If the next value is on the other side, the crossover happens on that tick. The first reading after a start never counts. After a deploy, restart or update, the Bot needs one reading to know which side it is on. Gaps are bridged. If a side is missing for a while, the next available reading is compared with the last one before the gap. Memory is per market and per pair. Each market remembers each left/right pair separately, and crosses_above and crosses_below on the same pair share that memory. Memory updates before the rules. It is updated once per tick, before any rule runs, so a tick on which an earlier rule fires still records which side each pair is on. The crossover itself is true only on that tick, though: if a rule higher up fires and ends the tick, a crossover rule below it misses that crossover. On a tick where take profit, stop loss or the ATR stop sent a close, rules don't run and crossover memory isn't updated. Once per candle with live candles. With candles: live, a pair of candle based fields crosses at most once per candle. No retry. A rule triggered by a crossover fires on the crossing tick only. If its order is skipped, blocked or unfilled, it waits for the next crossover. Not on setups. A crossover on a setup fails with setups are 1 or 0; compare them with ==, not a crossover. Actions Action Bot is flat Bot is long Bot is short open_long Opens a long of margin_usd × leverage Adds another full entry (same as add) Blocked: short position still open; close it first open_short Opens a short Blocked: long position still open; close it first Adds another full entry add Blocked: no open position Adds a full entry in the same direction Adds a full entry in the same direction reduce Does nothing Closes size_pct% of the position Closes size_pct% of the position close Does nothing Closes the whole position Closes the whole position Entries (open_long, open_short, add) follow execution and pass the same checks every time: the leverage cap, the one contract minimum, the funding veto, and your deployment's API error limit, order pacing and Max dollars per order. Exits (reduce, close) are immediate reduce only orders bounded by max_slippage_pct, limited to what your shared account can actually reduce. No automatic flip. To go from long to short, close first; the short can open on a later tick. Event contract actions such as buy_yes fail with action must be one of open_long, open_short, add, reduce, close. size_pct The share of the Bot's current position a reduce rule closes, in percent. Above 0 and up to 100; left out or 0 means 100. Other actions accept only 0 or 100 (otherwise size_pct is only used by reduce). The step is position × size_pct ÷ 100, rounded down to whole contracts (or to 0.01 on a market with fractional trading). 25% of 10 contracts is 2 contracts. If the step rounds to zero, as 25% of 3 contracts does, the reduce is skipped with reduce step rounds to zero. Note: A reduce rule written with comparisons fires on every tick while it holds, and each time it closes a share of what is left. To trim only once, pair it with a setup: require the setup == 0 and arm it on the reduce. See Add once, trim once. Missing data A rule never fires on missing data. If any comparison in a rule reads a missing value, the whole rule is false, even inside any. A crossover whose side is missing is simply not true on that tick. Values can be missing because: an indicator is still warming up, MACD is warming up, late, stale or has a gap, liquidation_price has no account position (and always in paper trading), the funding request failed. This fails safe for entries, but also for exits: an exit rule that reads a missing indicator doesn't fire until the value is back. Take profit and stop loss don't depend on indicators and keep working. Setups and setup rules A setup is a named flag that remembers an event between ticks, such as "a breakout happened" or "already trimmed this position". Each market keeps its own copy. Rules read it by name as 1 (armed) or 0. setups: at most 8, on custom only. Every declared setup must be armed by at least one rule or setup rule. setups[].name: same pattern as indicator names, unique, and different from base fields, MACD fields, your indicators and the reserved names exchange_position, account_unrealized_pnl and account_margin_used. setups[].expires_after_seconds: when set, from loop.interval to 604800 (7 days). Left out or 0 means it never expires. Expiry is checked at the start of each tick's rules, so it takes effect on the first tick at or after the deadline. Arming an armed setup restarts the clock. setup_rules: at most 16, and only when setups are declared. Each has a name, a when (same grammar, fields and operators as trading rules, including crossovers) and at least one of arm or clear. Setup rules never trade: an action on one is ignored. arm and clear on trading rules apply when the rule fires, right after its action, whether or not an order was placed or filled. Order on one tick: setup rules apply in list order, and the last arm or clear on a setup wins; a firing trading rule's arm or clear comes after them. A single rule can't arm and clear the same setup. Every setup is cleared by a stop, restart, redeploy or update (see Stops, restarts and updates). In the log. A rule that actually changes a setup logs armed or cleared after its rule name; re arming an armed setup restarts its clock without a log line. An expiry logs setup expired. Unlike trading rules, every setup rule whose conditions hold applies, in list order, and each sees the changes made by the ones above it. Trading rules then see the result on the same tick. A setup with no expiry and no rule that clears it stays armed until the Bot restarts. You can use that on purpose, for example to enter only once per run. Evaluation order For a custom strategy, the strategy step of each tick runs in this order, separately for each market: 1. Compute your indicators and any MACD fields your rules read. 2. Update crossover memory for every crossover pair in your rules and setup rules. 3. Clear setups whose expires_after_seconds has passed. 4. Apply every setup rule whose conditions hold, in list order. 5. Check trading rules top to bottom. The first one whose conditions hold runs its action and its arm/clear, and ends this market's tick. All of this happens only if take profit, stop loss and the ATR stop didn't send a close first (see What happens on every tick). Writing rules that behave Because the first match ends the tick, and comparisons fire on every tick, a few patterns keep custom strategies predictable: Guard exits with the position. An exit rule without position 0 (or 0.4e:T137a,Kalshi Perps Example Strategies This page collects complete Kalshi Perps strategies (platform: kalshi_perps): one trend_rider archetype and six custom strategies. For what each key does, see All Kalshi Perps parameters. Each example below saves and compiles as written. They show different ways to combine the keys documented in this section. The markets, sizes and thresholds are illustrative only, chosen to be small and easy to follow. They are not recommendations, and nothing here says any of them would be profitable. Trend entry on a crossover, with a stop A long only trend entry that fires once, on the tick the 20 candle EMA crosses above the 50 candle EMA. Two exits retry until flat: the trend turning back, and the price falling below the low of the previous 10 hourly candles. The percent take profit and stop loss run before any rule. If the entry is blocked on the crossing tick, for example by the market's leverage cap, it waits for the next crossover. After a stop loss, the Bot stays flat until the EMAs cross again. Pullback entry armed by a breakout A two stage entry. A setup rule arms breakout_seen when the price crosses above the 20 candle high while the trend is up. The entry waits for the price to pull back to the 20 candle EMA while staying above the 50 candle EMA. The setup expires after 4 hours, and it is cleared if the trend turns or when the entry fires. The entry's clear applies whenever the rule fires, even if the order is blocked, so a blocked pullback entry also ends the watch. The setup, like crossover memory, is cleared by a restart. Trend Rider on three markets, both directions The trend_rider archetype on three markets at once, using simple averages on 4 hour candles, trading both sides, with an ATR stop and a percent stop loss as a backstop. Each market is sized separately at $10 of notional. On a market where one contract costs more than $10, entries are skipped with margin x leverage below one contract. When the signal flips, the Bot closes first and opens the other side on a later tick. Add once, trim once Uses add, reduce and two setups as "do this once per trade" flags: enter when the price breaks above the previous 20 candle high while above a 50 candle EMA, add once on a fresh breakout, trim half once at $3 of unrealized profit, and exit fully below the EMA. The most this can hold is two entries, about $60 of notional. trimmed is armed whenever the trim rule fires, even if 50% rounds down to zero contracts. atr_1h 0 shows a readiness guard: a condition on an indicator the rule doesn't otherwise need, which holds the rule back until that indicator has a value. Here it changes nothing, because trend_ema needs 50 closed candles and warms up later than the 14 candle ATR. Bollinger fade with resting entries and a dollar bracket Mean reversion written as a custom strategy, with passive limit entries. It fades prices outside the Bollinger bands with an RSI filter, exits at the middle band or on a dollar take profit or stop written as one any rule, only enters while the account has a minimum available balance, and keeps a percent stop loss as a backstop. The entries are comparisons, so while flat and outside the band, the Bot keeps one resting entry on the book. Because limit_ttl_seconds equals loop.interval, an unfilled entry is cancelled on the next tick and replaced at the current price. available_balance is your whole perps account's balance, shared with other Bots, not a per Bot figure. MACD momentum on three markets with a 4h trend filter One rule set run separately on three markets: enter when the 5 minute Coinbase MACD histogram crosses zero in the direction of a 4 hour EMA trend, only while that side isn't paying funding, and exit when the histogram changes sign. Each market keeps its own crossover memory. If two markets cross on the same tick, the second entry can be skipped by order pacing, and because it is a crossover it waits for the next one. The explicit funding conditions repeat the automatic funding veto, with one difference: they also block entries while the estimate is missing. Up to three positions can be open at once, about $90 of notional, all on one margin account. trend_4h needs 50 completed 4 hour candles before entries can fire. MACD setup, then an EMA trigger, with a re entry window A two stage entry on 1 minute data. A strong bullish MACD cross arms long_setup, and a later 1 minute EMA cross enters. A bearish MACD cross exits (a comparison, so it retries) and opens a 6 minute window in which a fresh MACD cross can re enter. The re entry window is armed by a setup rule on the crossing tick, not by the exit rule, so it isn't re armed on every tick while the exit retries. The histogram threshold of 5 is in USD on BTC USD; it would need rescaling for any other coin. MACD comes from Coinbase spot, so rules that read it stop firing during a Coinbase data gap, while the stop loss keeps working. To trade shorts as well, add mirrored setups and rules.4f:T3cd3,Arbitrage Strategy Reference This section covers every parameter for platform: arbitrage. An arbitrage strategy trades two legs on two venues at once. Leg A is always Kalshi. Leg B is either regular (international) Polymarket or Polymarket US. The two legs name markets that should settle on the same real world outcome. You don't have to write the YAML yourself. You describe the pair in an Arbitrage chat in Studio, and Studio's AI writes the document. This section explains what each key does, so you can check the document before you deploy. Note: Turbine is not a financial advisor. Markets, tickers, prices and thresholds in this section are illustrative placeholders that show how parameters behave. They are not recommendations, and nothing here suggests a strategy will be profitable. In this section The arbitrage reference is split into these pages: Arbitrage Venues and Selectors: How each leg picks its market: the selectors Kalshi, Polymarket and Polymarket US accept, inline or nested selectors, how rolling legs are paired, and search placeholders that save as a draft but can't deploy. Arbitrage Outcome Mapping and Strategies: How mapping.a_yes_equals lines up the two legs' outcomes, and how the complementary, directional and custom strategies trade, including custom rule fields and actions. Arbitrage Risk Settings and Fees: Every risk key (per lock budget, net edge, slippage, unhedged time, resolution source mismatch), how a lock is placed, safety halts, the deploy dialog's limits, loop.interval, and the built in fee estimates and fees overrides. Arbitrage Buckets: How a Kalshi series and a rolling daily Polymarket US leg are matched bucket by bucket, such as daily temperature bands, and how bucket.select and bucket.bounds choose the pair to trade. Arbitrage Examples and Validation Errors: Seven complete strategies that pass Studio's checks, from fixed and rolling locks to directional buys and custom rules, plus common validation errors and what to change for each. This page keeps what every arbitrage strategy shares: how arbitrage works, the supported venue pairs, the full parameter table, backtesting and paper trading support, and the caveats to read before you deploy. How arbitrage works The built in strategy looks for a lock. It buys one outcome on Kalshi and the opposite outcome on leg B. If the two markets settle the same way, exactly one of the two contracts pays $1 and the other pays nothing. When the two asks plus fees come to less than $1, the difference is the lock's edge. For example, Kalshi YES at $0.42 plus Polymarket US NO at $0.53 costs $0.95 per pair. One of the two pays $1, so the pair has $0.05 of edge before fees. Every loop.interval seconds, the Bot: 1. reads both order books, 2. prices both ways to lock (Kalshi YES with one leg B side, and Kalshi NO with the other), including estimated fees, 3. keeps the better one, and trades it only if its net edge is at least risk.min_net_edge_bps, 4. places one leg, then the other straight away (see How a lock is placed), 5. holds both legs until the markets settle. There's no take profit, stop loss or early exit. The Bot can lock again on a later loop while the edge, your balances and your deployment risk limits last. Warning: A lock is not risk free. The two venues can settle on different sources or rules, the second leg can fail after the first one fills, and prices can move between the two orders. Read Caveats before you deploy. Supported venue pairs There are two venue pairs. You pick one when you start an Arbitrage chat, and the chat stays on that pair. To trade the other pair, start a new chat. Kalshi + Polymarket appears only where regular Polymarket is available to you. Kalshi + Polymarket Kalshi + Polymarket US venues.b.platform polymarket polymarket_us Fixed leg B market condition_id + yes_token_id + no_token_id slug Rolling leg B markets series_slug, or recurring crypto up/down series recurring daily events, paired by bucket Leg placed first Polymarket, always The leg with more visible depth; Kalshi on a tie or when depth is unknown Leg B order Limit order; whatever doesn't fill at once is cancelled Fill or kill Leg B fee estimate The market's live fee rate Polymarket US's published taker formula Leg B minimum order The market's minimum, usually 5 shares 1 contract Runs on Your Polymarket runner Your Kalshi runner Leg A is always Kalshi, and the legs can't be swapped. There is no Polymarket + Polymarket US pair, no Kalshi + Kalshi pair and no Kalshi Perps arbitrage. Arbitrage needs an active Studio subscription. The platform value Every arbitrage document uses platform: arbitrage (letter case doesn't matter). The venue pair comes from venues.b.platform, not from platform. Deploy time names such as arbitrage_kalshi_polymarket and arbitrage_kalshi_pmus are not valid here: All arbitrage parameters Every key an arbitrage document accepts is listed below. Rows that link to a section have behavior worth reading about. Studio rejects an unknown top level key. Most unknown keys inside a block, such as risk.max_notional or fees.c, are ignored without an error, so check spelling. Keys inside rules are the exception: unknown rule and condition keys are rejected. Whole number keys must be whole: min_net_edge_bps: 12.5 fails with risk.min_net_edge_bps: must be a whole number, got 12.5. Document keys Parameter Type Default Allowed values What it does version integer required 1 Document version. platform string required arbitrage Marks a two leg arbitrage document. strategy string required complementary, directional, custom Hedged lock, single leg buy, or your own rules. Case doesn't matter. strategy_name string none any text; Studio trims it to 80 characters Display name. Studio sets it when it saves, so a hand edit can be replaced. No effect on trading. strategy_name_origin string generated user, generated, curated. Older legacy and unknown values are saved as generated Where the name came from. Metadata only. Venues and markets Parameter Type Default Allowed values What it does venues.a.platform string required kalshi Leg A is always Kalshi. venues.b.platform string required polymarket, polymarket_us Picks the venue pair. venues.a.market, venues.b.market map required the selector keys below, under market or directly on the leg The market each leg trades. Each leg needs at least one selector. venues.a.market.ticker string none a Kalshi market ticker One fixed Kalshi market. venues.a.market.series_ticker string none a Kalshi series ticker Follows the series' current market. Required with a rolling daily Polymarket US leg. venues.a.market.event_ticker string none a Kalshi event ticker Search placeholder. Saves as a draft that can't deploy. venues.a.market.query, venues.b.market.query string none free text Search placeholder on either leg. Saves as a draft that can't deploy. venues.b.market.slug string none a market slug Polymarket US: the fixed market. Polymarket: a label only. venues.b.market.event_slug string none an event slug Search placeholder. Saves as a draft that can't deploy. venues.b.market.series_slug string none a Polymarket series slug such as btc up or down 15m Polymarket only: follows the series' current market. venues.b.market.condition_id string none a Polymarket condition ID Polymarket only: the fixed market. Needs both token IDs. venues.b.market.yes_token_id string none a token ID Polymarket only: the token the Bot buys as leg B YES. venues.b.market.no_token_id string none a token ID Polymarket only: the token the Bot buys as leg B NO. venues.b.market.neg_risk boolean false false Polymarket only. true is rejected: multi outcome markets aren't supported. venues.b.market.tick_size string "0.01" a price step such as "0.01"; not checked when you save Polymarket only: fallback price step if the live one can't be read. venues.b.market.min_order_size number (quoted or unquoted) 5 a positive number such as 5 or "5" Polymarket only: smallest order on a fixed market. venues.b.market.recurring map none Polymarket: kind, asset, interval. Polymarket US: kind, event_slug_prefix Rolling leg B markets. venues.b.market.recurring.kind string updown on Polymarket; required on Polymarket US Polymarket: updown. Polymarket US: daily The kind of rolling market. Case doesn't matter. venues.b.market.recurring.asset string none btc, eth, sol, xrp, doge, hype, bnb Polymarket only: the crypto asset. venues.b.market.recurring.interval string none 5m, 15m, 1h, 4h, 1d Polymarket only: the window length. venues.b.market.recurring.event_slug_prefix string none an event slug without its date, such as temp nychigh Polymarket US only: the daily event family. Ignored on Polymarket. venues.a.market.selection, venues.b.market.selection string none not allowed Rejected. Use bucket.select. Mapping, risk and loop Parameter Type Default Allowed values What it does mapping.a_yes_equals string required b_yes, b_no Which leg B outcome is the same event as Kalshi YES. Decides which pairs the Bot buys. mapping.leg_a_yes_to.leg_b_side string none yes, no, b_yes, b_no Older spelling of a_yes_equals. Used only when a_yes_equals is missing. mapping.leg_a_no_to map none anything Older key. Accepted and ignored. risk.max_position_usdc number ($) required above 0 Most dollars one lock may spend across both legs; not a lifetime cap. For directional, the cap on the whole position. risk.min_net_edge_bps integer (bps of $1) 0 0 or more Minimum edge after estimated fees before the Bot trades. risk.max_leg_slippage_bps integer (bps of price) 25 0 or more How far above the quoted ask each order's limit may sit. risk.max_unhedged_seconds integer (seconds) 10 0 or more; don't use 0 Longest the second leg may take before the Bot halts itself. risk.accept_resolution_source_mismatch boolean false true, false Records that you accept the two markets may settle differently. Doesn't change trading. loop.interval integer (seconds) required 10 or more Seconds to wait after each loop. Fees and buckets Parameter Type Default Allowed values What it does fees map none a, b Optional overrides for the fee estimates used in edge checks. fees.a.flat_bps integer (bps of notional) none 0 or more Kalshi estimate: a flat share of notional. fees.a.fee_rate_bps integer none not allowed Rejected: it's a Polymarket fee input. Use fees.a.flat_bps. fees.b.flat_bps integer (bps of notional) none 0 or more; not with fee_rate_bps Leg B estimate: a flat share of notional. fees.b.fee_rate_bps integer (bps) none 0 or more; not with flat_bps Leg B estimate: a Polymarket style rate × min(p, 1 − p). bucket map none select, bounds Only with a rolling daily Polymarket US leg: which matched bucket to trade. bucket.select string all all, nearest_even_odds, max_volume, pinned_bounds How the bucket is chosen. bucket.bounds.gte number none a whole number Lowest value in the pinned bucket, inclusive. Only with pinned_bounds. bucket.bounds.lte number none a whole number Highest value in the pinned bucket, inclusive. Only with pinned_bounds. Directional params Parameter Type Default Allowed values What it does params map none leg, side, max_price, size Read only by strategy: directional. The other strategies ignore it. params.leg string b a (Kalshi), b (leg B) Which venue to buy on. params.side string yes yes, no Which outcome to buy. params.max_price number ($) 0 (never buys) a price above 0 (0 or missing never buys; not checked when you save) Highest ask the Bot will pay. params.size integer (contracts) 1 1 or more Contracts per buy. Raised to the leg's minimum order size, then cut to what fits under the position cap and the deploy limits. Custom rules Parameter Type Default Allowed values What it does rules list required for custom 1 or more rules Ordered rules. The first match each loop acts. rules[].name string required non empty text Label in logs. rules[].when.all or rules[].when.any list of conditions required (exactly one) all: every condition true. any: at least one The rule's trigger. [rules[].when.[].field](/docs/strategy reference/arbitrage/strategies#custom rule fields) string required the 11 arbitrage fields The value to test. rules[].when.[].op string required , =, ==, != Comparison. Quote it: op: " =". [rules[].when.[].value](/docs/strategy reference/arbitrage/strategies#custom rule fields) number one of value or value_field an unquoted, finite number (true/false for halted) What to compare against. rules[].when.[].value_field string one of value or value_field any arbitrage field Compare against another live value. [rules[].action](/docs/strategy reference/arbitrage/strategies#custom rule actions) string required execute_lock, cancel_all, skip What happens when the rule matches. [rules[].size and other single venue rule keys](/docs/strategy reference/arbitrage/strategies#custom rule actions) varies none accepted when well typed Ignored by arbitrage. size doesn't size a lock. The deploy dialog's Max contracts per order, Max dollars per order, Max open contracts and Max daily notional traded also limit every buy, including each lock. They aren't YAML keys; see Deployment risk limits. Backtesting and paper trading Arbitrage strategies can't be backtested, and there is no paper mode. An arbitrage Bot's first run is live, with real orders on both venues. Start with small deploy limits and watch the first locks closely. Caveats Settlement differences (basis risk). A lock only pays out as planned if both markets settle the same way. Venues can use different data sources, cut off times and rules for edge cases, and then both legs can lose. accept_resolution_source_mismatch records that you accepted this; it doesn't reduce it. Legging risk. Between the first fill and the hedge you hold one side alone. If the hedge fails or is late, the Bot halts and leaves that position open. Prices move. The edge is measured at quoted asks. Slippage and a moving market during the hedge can turn a planned lock into a loss. Fees are estimates. They follow each venue's published or live rate, but venues can change fees, and overrides replace the estimate only. Locks add up to your deploy limits. max_position_usdc caps each lock, not your total. Repeated locks stop only at Max open contracts (per leg) and Max daily notional traded, so set those to the most you want held and traded. Polymarket collateral. On Kalshi + Polymarket, a Polymarket order the Bot refuses just before sending, for example because your collateral doesn't cover it at its slippage limit, halts the Bot even though no order was placed. Keep your Polymarket collateral above what one lock can spend at its slippage limit. Leg B cancels take only this Bot's orders. Polymarket and Polymarket US orders carry no client id, so the Bot remembers the id of every leg B order the exchange accepts from it; the memory survives restarts and redeploys, but not stopping the Bot. The cancel_all action, the cleanup before a partial fill or hedge halt, and the cancel that follows each regular Polymarket order touch only those ids, never orders you placed by hand or another Bot's. Studio still won't deploy a second arbitrage Bot on a leg B market that a running arbitrage Bot already trades, because both would size against the one position your account holds there. Markets end. A fixed Kalshi ticker stops the Bot once it closes. A closed fixed leg B market makes every loop skip. Fail closed data. Stale quotes, a one sided book, a missing Polymarket fee rate or an unreadable position make the Bot skip the loop rather than guess. Read Risk & Limits before you deploy.50:T1f9b,Arbitrage Venues and Selectors This page covers the venues block of an arbitrage strategy (platform: arbitrage): how leg A (Kalshi) and leg B (Polymarket or Polymarket US) each pick a market, how the two legs stay lined up when their markets roll, and which selectors save only as a draft. For the two venue pairs and how they differ, see Supported venue pairs; for every venue key at a glance, see All arbitrage parameters. Each leg is a venue plus a market selector: Which selector keys work depends on the leg's venue. A key that belongs to another venue is rejected. Search placeholders save as a draft that can't deploy yet; see Draft selectors. To deploy, each leg needs one deployable selector: Kalshi: ticker or series_ticker, not both. Polymarket: condition_id with both token IDs, or series_slug, or recurring. Polymarket US: slug or recurring, not both. Inline or nested selectors Selector keys can sit under market, or directly on the leg. These two are the same: If one leg uses both forms, they're merged key by key, and a key under market wins without a warning. Mixing can also leave two conflicting selectors: an inline ticker plus a nested series_ticker keeps both and can't deploy ("must use either market.ticker or market.series_ticker, not both"). Use one form per leg. Error messages name the path as venues.a.market or venues.b.market either way. (Regular Polymarket recurring errors are the exception: they start at market.recurring… or market.series_slug.) Unknown keys inside a leg are ignored, so a misspelled selector is only caught when it leaves the leg with no selector at all. Kalshi leg A ticker pins one Kalshi market. When that market has closed or settled and its book is empty, the Bot stops. series_ticker follows a repeating series, such as a 15 minute crypto series or a daily temperature series. The Bot uses the series' open market that closes soonest, preferring markets with quotes. When that market closes, the Bot waits for the next one. How it lines up with leg B is covered in Rolling markets. The ticker also sets the Kalshi fee estimate; see Built in fee estimates. market.selection, which single venue Kalshi strategies use to pick a bracket, is rejected here. For bucketed daily series, use a rolling Polymarket US leg with bucket. Polymarket leg B A fixed Polymarket leg needs all three of condition_id, yes_token_id and no_token_id. Studio's Polymarket search finds them. The other keys are optional: slug is a readable label. On its own it can't deploy, and Studio saves the strategy as a draft. neg_risk: false is optional documentation. neg_risk: true is rejected: negative risk, multi outcome markets aren't supported. tick_size is a fallback. The Bot reads each token's live price step and uses this value only if that read fails. Default "0.01". Studio doesn't check this value here, so a typo such as "0.5" saves. Copy it from Studio's Polymarket search. min_order_size is the market's smallest order, default 5. Every lock must reach it. The deploy dialog's Max contracts per order must be at least this size. The dialog raises it to at least 5 for this pair, so if a market's minimum is higher, raise the limit or every lock is skipped. Write a positive number (5 or "5"); anything else, such as "abc" or 0, is rejected when you save. mapping.a_yes_equals is read against yes_token_id: "leg B YES" means whichever outcome that token is. If you swap the two token IDs, flip the mapping too. A rolling Polymarket leg follows a repeating crypto up/down series. Write the series slug yourself, or let recurring build it. These two are the same: asset Also accepts btc bitcoin eth ethereum, ether sol solana xrp ripple doge dogecoin hype hyperliquid bnb binance interval Also accepts Series it follows 5m 5min, 5mins up or down 5m 15m 15min, 15mins up or down 15m 1h hour, hourly up or down hourly (solana for sol) 4h none up or down 4h 1d day, daily up or down daily (solana for sol, dogecoin for doge) Case doesn't matter, and spaces and hyphens in interval are ignored, so 15 min works too. How a rolling Polymarket leg behaves: The Bot trades the series' active market that ends soonest. From 10 seconds before that market ends, it re checks the series on every loop, and moves to the next market once the current one has ended. The market must be binary (Yes/No or Up/Down) and not negative risk. On Up/Down markets, leg B YES is Up. If you set series_slug and token IDs, the series wins. If you set series_slug and recurring, they must name the same series. event_slug_prefix belongs to Polymarket US and is ignored here. A line that reads exactly recurring: true or recurring: yes is ignored. If that was the leg's only selector, the leg has none and is rejected. Any other single value, such as recurring: false, rejects the save with a YAML error. Use a full recurring block or series_slug. Polymarket US leg B slug pins one Polymarket US market. Many slugs include a date, so a pinned slug stops trading once that market closes. recurring with kind: daily and event_slug_prefix follows a daily event family, such as a city's daily high temperature. Each day's event has several bucket markets, which the Bot matches to the Kalshi series' markets. See Buckets. Rules for a rolling daily leg: Leg A must use series_ticker, so both legs roll together. Don't combine it with slug. event_slug_prefix is the event slug without its date. The Bot adds YYYY MM DD for yesterday, today and tomorrow (UTC), and uses the open event whose markets close soonest, at least a minute from now. Don't include the date, or the tc prefix that the event's market slugs carry. asset and interval are rejected here. Polymarket US also rejects the regular Polymarket keys: condition_id, the token IDs, neg_risk (even false), tick_size, min_order_size and series_slug. A rolling daily leg with a fixed Kalshi ticker is rejected: Rolling markets How the two legs line up depends on which of them roll: Leg A Leg B How the legs are paired ticker Polymarket token IDs, or a Polymarket US slug Both fixed. You choose the pair. series_ticker Polymarket series_slug or recurring Each window, the Kalshi market that closes within 120 seconds of the Polymarket market. If none does, or more than one does, the loop skips. series_ticker Polymarket US slug The Kalshi market that closes within 120 seconds of the Polymarket US market. After that market closes, leg B can't roll. series_ticker Polymarket US recurring Buckets are matched every day. See Buckets. ticker Polymarket US recurring Rejected. series_ticker Polymarket token IDs Rejected. Only Kalshi would roll, so the legs would trade different windows. ticker Polymarket series_slug or recurring Rejected. Only leg B would roll, so later windows wouldn't match. As a second line of defense, once either leg rolls the Bot checks right before placing each lock that both legs' markets close within 120 seconds of each other. If they don't, or either close time is unknown, it skips the lock and logs "refusing arbitrage lock". Two fixed legs are never checked: you chose that pair. A rolling leg next to a fixed one is rejected. Here the Kalshi series rolls to a new 15 minute market every window, while leg B stays on one Polymarket market: A Kalshi series that lists several markets with the same close time, such as daily temperature bands, can't be paired with a Polymarket series or a Polymarket US slug. The Bot skips and logs that the series "cannot be auto paired". Use a rolling daily Polymarket US leg with bucket matching, or pin ticker to one band and pair it with a fixed leg B market. Draft selectors query (either leg), Kalshi event_ticker and leg B event_slug are search placeholders. So is a Polymarket slug without token IDs. Studio's AI uses them while it's still looking for the exact market. Studio saves the strategy as a draft, and you can't deploy it until each leg has a deployable selector and no placeholder is left. A leftover placeholder blocks deploy even next to a deployable selector: To fix it, ask Studio to resolve the exact markets and remove the search fields.51:T24a9,Arbitrage Outcome Mapping and Strategies This page covers two keys every arbitrage strategy (platform: arbitrage) sets. mapping tells the Bot how leg B's outcomes line up with Kalshi's. strategy picks how the Bot trades: a hedged complementary lock, a single leg directional buy, or your own custom rules. For every key at a glance, see All arbitrage parameters. Outcome mapping mapping.a_yes_equals This key tells the Bot which leg B outcome is the same event as Kalshi YES. Every strategy needs it. b_yes: both venues describe the event the same way. Kalshi YES and leg B YES happen together. b_no: the labels are inverted. Kalshi YES happens exactly when leg B NO happens. For example, take Kalshi's "Celtics win" market for a Lakers at Celtics game. Against Polymarket's "Will the Celtics beat the Lakers?", the mapping is b_yes. Against "Will the Lakers beat the Celtics?", it's b_no. A lock buys opposite outcomes, so the mapping decides which two pairs the Bot can buy: complementary and custom price both pairs every loop and take the one with the better net edge. directional doesn't use the mapping, but it's still required. For a Polymarket leg, leg B YES is the yes_token_id outcome, whatever the market calls it. On Up/Down series it's Up. Warning: Studio can't check that the mapping is right. With the wrong value, both legs pay on the same outcome: instead of a hedge, you hold twice the exposure to one result. Read both markets' rules and confirm which outcome matches before you deploy. See Inverted labels on Polymarket for a complete b_no example. Older mapping keys Older drafts wrote the mapping like this: leg_b_side accepts yes, no, b_yes or b_no (letter case doesn't matter). It's read only when a_yes_equals is missing. If both are set, a_yes_equals wins without a warning. A leg_a_no_to block and rationale keys are ignored, even when they contradict leg_a_yes_to. Any other value is rejected as mapping.a_yes_equals: must be b_yes or b_no. Use a_yes_equals. Strategies strategy picks one of three ways to trade: complementary directional custom What it does Hedged lock across both venues Buys one side on one venue Your rules decide when to lock, cancel or skip Hedged Yes, when both legs fill No Yes, when a rule runs execute_lock mapping.a_yes_equals Picks the lock pairs Required, not used Picks the lock pairs risk.max_position_usdc Per lock budget Position cap: this ÷ max_price contracts Per lock budget for execute_lock risk.min_net_edge_bps Lock edge after fees Edge below max_price after fees Always applied by execute_lock risk.max_leg_slippage_bps Both legs The single order Both legs of execute_lock risk.max_unhedged_seconds Used Not used Used by execute_lock params Ignored Read Ignored rules Never run Never run Required On complementary and directional, a rules block never runs, but Studio still checks its shape. An unknown rule key or a badly typed value there rejects the save. complementary The built in hedged lock described in How arbitrage works. Each loop it prices both lock pairs, keeps the better one, and places the lock only when every check passes: edge, size, visible depth and fresh quotes. It needs no params or rules. directional Warning: directional is not arbitrage. It buys one side on one venue and holds it without a hedge. Each loop, the Bot reads the ask for params.side on params.leg and buys when both of these hold: the ask is at or below params.max_price, and (max_price − ask) × 10,000, minus the estimated fee in bps, is at least risk.min_net_edge_bps. For example, with max_price: 0.40 and min_net_edge_bps: 200 on Polymarket US: at a 0.36 ask the fee rounds to $0.02 (200 bps), so the edge is 400 − 200 = 200 and the Bot buys. At 0.37 the edge is 300 − 200 = 100, so it skips. The order's limit is the ask plus max_leg_slippage_bps, so it can sit slightly above max_price. Things to know: It builds a position. The Bot buys again on every loop while the condition holds, and every buy adds to one position on that leg and side. It never sells: the position stays open until the market settles or you close it yourself. max_position_usdc caps the position. The Bot holds at most max_position_usdc ÷ max_price contracts on its leg and side, rounded down: the number that budget buys at the highest ask it pays. $10 at 0.40 is 25 contracts. Before each buy it reads what the venue says that market already holds, so contracts from before a restart, or ones you bought by hand, count too. Contracts on the other side don't count toward this cap, but they do count toward Max open contracts. The order's slippage allowance can take the cost slightly past the budget. Size. Each buy is params.size contracts, raised to the leg's minimum order size (usually 5 on a Polymarket leg, 1 elsewhere). The Bot then cuts it to what fits under the position cap, Max contracts per order, Max dollars per order, Max open contracts and Max daily notional traded; see Deployment risk limits. When less than the minimum fits, it skips and logs "directional buy blocked by" and the limit's name. Nothing inside params is checked when you save. A misspelled key such as max_prce is ignored, so max_price stays 0 and the Bot never buys. An invalid leg or side makes every loop skip. A word where a number belongs (max_price: abc, size: lots) or a quoted decimal (size: "2.7") saves, then stops the Bot at startup. Write plain numbers. params itself must be a block of keys: a list or a single value (params: [1, 2], params: 5) rejects the save. Logs explain a Bot that never buys. A Bot with no max_price logs "directional max_price missing; fail closed without placing orders", and a bad leg or side logs "directional params.leg must be a or b" or "directional params.side must be yes or no" every loop. Rolling legs. The position cap applies to one market at a time, so each new window or daily event starts from zero; Max daily notional traded is what bounds a day. With a recurring Polymarket US leg B, leg: b buys in the bucket the Bot pairs when it first resolves each day's event, and stays on it until that market closes. Without bucket.select, that's the bucket with the best lock edge at that moment, which says nothing about direction, so set bucket.select: pinned_bounds to choose it yourself. mapping is required but not used, and max_unhedged_seconds doesn't apply. See Directional buy on one venue for a complete example. custom Custom arbitrage strategies use ordered rules like Custom Rules on single venues, with their own fields and actions. Each loop: 1. The Bot reads all four asks, both balances, and the better lock pair's cost, edge and fees. If any of these can't be read, for example because one side has no ask, no rule runs that loop. 2. It checks the rules from top to bottom. 3. The first rule whose when block is true runs its action, and the loop ends. If no rule matches, nothing happens. Put guard rules, such as skip and cancel_all, above the rule that locks. Custom rule fields Field Meaning leg_a.yes_ask Kalshi YES ask, in dollars (1 − the best NO bid). leg_a.no_ask Kalshi NO ask (1 − the best YES bid). leg_a.balance Kalshi cash balance, in dollars. leg_b.yes_ask Leg B YES ask. On Polymarket, the YES token's ask. leg_b.no_ask Leg B NO ask. On Polymarket US, 1 − the best YES bid. leg_b.balance Polymarket collateral or Polymarket US buying power, in dollars. combined_cost The two asks of the better lock pair, added together, in dollars. net_edge_bps Net edge of the better lock pair at 1 contract, after estimated fees. fee_a Estimated Kalshi fee for 1 contract of the better pair, in dollars. fee_b Estimated leg B fee for 1 contract of the better pair, in dollars. halted Accepted, but always false while rules run: a halted Bot stops before it checks rules. Don't use it. Field names are case sensitive. Single venue fields such as price, spread, time_to_expiry, edge. and derived. are rejected. Compare against an unquoted number (value: 0.95) or another field (value_field: leg_b.yes_ask). Set exactly one of the two. A quoted number such as value: "0.5", a duration string such as "5m", .nan and .inf are rejected (must be a number, must be finite). halted also accepts true or false. Custom rule actions Action What it does execute_lock Runs the full hedged lock with every check: min_net_edge_bps (at 1 contract and at the lock size), sizing (including Max open contracts and Max daily notional traded), slippage and the unhedged time halt. The rule's conditions only decide whether to try. cancel_all Cancels this Bot's resting orders in the current Kalshi market and the leg B market. Orders you placed by hand and other Bots' orders stay. It never closes positions. skip Does nothing this loop. Use it to guard the rules below it. Actions are case sensitive. Single venue actions such as buy_yes and sell_all are rejected, and so are the reserved buy@a, buy@b, sell_all@a and sell_all@b. Custom arbitrage has no required exit rule, because locks are held to settlement. Rule keys from single venue custom rules (size, max_combined_price, orders, trading_schedule, entry_profit_offset, entry_stop_loss_offset, entry_profit_targets and entry_profit_min_time_to_expiry) are accepted when well typed, then ignored. size: 5 doesn't size a lock; see risk.max_position_usdc. Any other rule key is rejected. See Custom rules on a rolling pair for a complete strategy.52:T3ca5,Arbitrage Risk Settings and Fees This page covers the settings that decide how much an arbitrage Bot (platform: arbitrage) spends and when it trades: the risk block, the deploy dialog's per order limits and loop.interval. It also explains how a lock is placed, when the Bot halts, and the fee estimates behind every edge check, including the fees overrides that replace them. For every key at a glance, see All arbitrage parameters. Risk settings The risk block sets what one lock may spend and when the Bot may trade. The deploy dialog adds a second layer; see Deployment risk limits. risk.max_position_usdc The most one lock may spend across both legs, in dollars. It's required and must be above 0. It's a per lock budget, not a cap on your total position. The Bot can lock again on the next loop, and each new lock can spend up to this amount again while the edge and your balances last, until Max open contracts or Max daily notional traded leaves no room; see Deployment risk limits. The number of contracts in a lock is the smallest of these caps, rounded down: Cap Formula Illustrative value Strategy budget max_position_usdc ÷ (ask A + ask B) $25 ÷ 0.95 = 26.3 Kalshi balance cash ÷ ask A $40 ÷ 0.42 = 95.2 Leg B balance balance ÷ ask B $30 ÷ 0.53 = 56.6 Max dollars per order limit ÷ (ask A + ask B) $1 ÷ 0.95 = 1.05 Max contracts per order limit 1 Max open contracts limit − contracts already held in that leg's market, on each leg 25 − 0 = 25 Max daily notional traded (limit − today's fills) ÷ (limit price A + limit price B) $25 ÷ 0.952 = 26.2 Visible depth contracts at the best ask, on each leg 120 and 35 With these numbers the lock is 1 contract, because the deploy limits Studio pre fills for Kalshi + Polymarket US (1 contract and $1 per order) are the smallest caps. For Kalshi + Polymarket, Studio pre fills 5 contracts and $5 per order ($5 ÷ 0.95 = 5.26), so the same lock would be 5 contracts. With deploy limits of 20 contracts and $25 per order, it would be 20 contracts. The lock must also reach the larger of the two venue minimums: 1 contract on Kalshi and Polymarket US, and the market minimum (usually 5 shares) on Polymarket. Below that, the Bot skips. For directional it caps the whole position instead of each buy; see directional. risk.min_net_edge_bps The minimum edge after estimated fees before the Bot trades, in basis points of the $1 payout: 100 bps is 1 cent per contract. The default is 0, so when you leave it out, any lock whose estimated fees don't exceed its gross edge can trade. Net edge in bps = ((1 − ask A − ask B) × contracts − fee A − fee B) ÷ contracts × 10,000. A lock is checked three times: at 1 contract on fresh quotes, at the lock size after a re quote, and once more after the legs are ordered and quoted again. All three checks use the quoted asks, not the limit prices the orders are sent at. Two things can take a filled lock below your minimum: Slippage. Each order may fill up to max_leg_slippage_bps above its ask, and the edge check doesn't include that allowance. Moves during the hedge. The second leg is sent at a fresh ask without a new edge check. At 1 contract, Kalshi's fee estimate rounds up to a whole cent: $0.02 (200 bps) for prices between about 18¢ and 82¢, and $0.01 outside that range (standard 0.07 rate; INX and NASDAQ100 tickers are $0.01 at every price, and a fees.a override replaces this estimate). Small edges rarely pass the first check. For directional the check is different; see directional. For custom, execute_lock always applies this minimum, whatever the rule's own thresholds. risk.max_leg_slippage_bps How far above the quoted ask each order's limit may be, as a share of the ask. The default is 25 (0.25%). It applies to both legs of a lock and to directional buys. Limit = ask × (1 + max_leg_slippage_bps ÷ 10,000), capped just below $1. Unlike min_net_edge_bps, these basis points are of the price, not of the $1 payout. The limit is then rounded to the venue's price grid, so small values can round away: Venue How the limit is rounded Ask 0.42 with 25 bps 100 bps 150 bps Kalshi Nearest cent 0.42105 → 42¢ 0.4242 → 42¢ 0.4263 → 43¢ Polymarket US Nearest cent 42¢ 42¢ 43¢ Polymarket Down to the market's price step 42¢ 42¢ 42¢ with a 1¢ step At a 42¢ ask on Kalshi, anything below about 120 bps still sends 42¢. An explicit 0 sends the order at the ask. On Polymarket US, a NO order's limit is sent as a YES price and rounded there. A NO ask of 0.53 with 150 bps gives 0.53795, sent as YES 0.46, which is a NO limit of 0.54. risk.max_unhedged_seconds The longest the second leg may take, in seconds. The default is 10. The clock starts once the first leg has fully filled. It covers re quoting the second leg, sending it and confirming the fill. If that took longer than this limit, the Bot cancels its open orders and halts, even if the hedge filled. The check happens after the hedge returns: it never cancels the hedge early, and it never sells the first leg. 0 halts the Bot after every lock, because some time always passes. Don't use 0. A partly filled or unconfirmed first leg halts the Bot whatever this is set to. directional doesn't use it. risk.accept_resolution_source_mismatch Your explicit acceptance that the two markets may settle from different sources or rules. The default is false. It changes nothing about how the Bot trades. It's a record. When Studio's AI finds a settlement difference between the two markets, it lists it and asks whether you accept it. Studio won't save a strategy whose YAML, comments included, contains a settlement caveat, such as the phrases "resolution source mismatch", "resolution caveat", "mismatch risk", "candidate only" or "trimmed mean vs spot", until this is true. With true, Studio describes the Bot as carrying accepted basis risk, never as risk free. Setting it doesn't make a lock safer. If the markets settle differently, both legs can lose. Studio's own crypto templates, for example, warn that Kalshi and Polymarket settle their short window crypto markets on different price sources, so the legs can resolve differently near a price boundary. How a lock is placed Placement is the riskiest part of a lock: between the first fill and the second, you hold one side alone. This applies to complementary and to execute_lock in custom. Which leg goes first: Kalshi + Polymarket: Polymarket, always. Its order is a limit order; whatever doesn't fill at once is cancelled, and the Bot waits up to about 4 seconds to confirm the fill before it sends the Kalshi leg. Kalshi + Polymarket US: when both books show depth at the best ask, the leg with more depth goes first. Otherwise, or on a tie, Kalshi goes first. Kalshi orders are immediate or cancel limit orders, and Polymarket US orders are fill or kill, so no order is left resting. The second leg is sent for the quantity the first leg filled, at a fresh ask plus slippage, without a new edge check. If prices moved, the hedge can cost more than planned. Quotes must be no more than 5 seconds old at each check. Safety halts When something goes wrong once the Bot starts placing a lock, it writes a safety halt. For a partial first leg, or a hedge that failed, filled a different quantity or took too long, it first cancels its open orders. When the first order failed or its fill status is unknown, it halts without cancelling anything. It halts when: sending the first order failed after it may have reached the venue, or its fill status is unknown, on Kalshi + Polymarket, the Bot refused the Polymarket order just before sending it, for example because your Polymarket collateral doesn't cover the order at its slippage limit, or the Bot's Polymarket trading approvals failed when it started (no order is placed, but the Bot still halts), the first leg filled only partly (the partial fill is not hedged), the hedge order failed, the hedge filled a different quantity than the first leg, the hedge took longer than max_unhedged_seconds, even if it filled. Halt log lines start with SAFETY_HALT and name the reason: Reason in the log What happened first_leg_unknown_or_failed Sending the first order failed after it may have reached the venue. On Kalshi + Polymarket, this also covers a Polymarket order refused just before sending. first_leg_fill_unknown_after_order The first order was sent, but its fill couldn't be confirmed. first_leg_filled_second_leg_failed The first leg filled, then the hedge failed, filled a different quantity or was late, or the first leg filled only partly. The log also names the cause, such as second_leg_exceeded_max_unhedged_seconds (the hedge was late), second_leg_fill_mismatch (the hedge filled a different quantity) or first_leg_partial_fill_before_second_leg (the first leg filled only partly and was not hedged). A halt doesn't unwind anything. There's no automatic recovery or flattening: a one sided position stays open until the market settles or you close it yourself. While halted, the Bot logs SAFETY_HALT and places no orders. How a halt clears: Rolling strategies (leg A uses series_ticker, or leg B rolls) clear a halt on their own when the first leg was on Kalshi and that market has closed or settled, when about 30 minutes have passed since the halted markets closed, or when Kalshi confirms that an unconfirmed first order was never placed or never filled. Trading then resumes on the current market. Clearing the halt doesn't close anything from the halted window. Fixed market strategies never clear a halt on their own. The Bot stays halted. When a Bot halts, check both venues for a one sided position and decide what to do with it yourself. For a fixed market Bot, stop it once you've reconciled both accounts. See Monitoring. Some stops don't write a halt: API errors. When the deploy dialog's API error limit is reached inside its error window (3 errors in 5 minutes by default), the Bot pauses new locks for one window, logs "API error breaker tripped", then resumes on its own. Errors older than the window don't count. Fixed Kalshi market closed. The Bot stops. Missing data. Stale quotes, a one sided book, a Polymarket fee rate, or a position that can't be read make the Bot skip that loop rather than guess. Deployment risk limits Four of the deploy dialog's limits size every buy: both legs of a lock, and each directional buy. Sizing checks them before the first order of a lock; the hedge is never refused, because that would leave the first leg unhedged. Limit What it caps Studio pre fills Max contracts per order Contracts in one order 1 Max dollars per order One order's cost: both legs together for a lock $1 Max open contracts Contracts held in each leg's current market, both sides, as that venue reports them, plus the new order max_position_usdc, rounded up Max daily notional traded This Bot's fills since 00:00 UTC on both legs, valued at their limit prices, plus the new order max_position_usdc rounded up, or $10 if that's higher For Kalshi + Polymarket, the dialog raises Max contracts per order, Max dollars per order and Max open contracts to at least 5, so an order can reach Polymarket's usual 5 share minimum. When the running Bot's limits can be verified, the redeploy dialog starts from those limits. If readback is missing or unverified, review the suggested limits before confirming an update; see deployment risk settings. See the sizing table in risk.max_position_usdc for how they combine. Max open contracts counts everything the account holds in that market, including contracts you or another Bot bought there. If the Bot can't read a position, it skips the loop. The daily total is kept in a file next to the Bot's safety halt marker: restarting the Bot doesn't reset it, but a runner upgrade that rebuilds the runner does. Arbitrage Bots don't read Max daily loss. The API error limit and window set the stop described in Safety halts. Each leg trades from your account on that venue, so its balance is shared with every other Bot (on any runner) and any manual trading that uses the same account. See Run. loop.interval Seconds the Bot waits after each loop before starting the next. It's required, and must be an unquoted number of 10 or more. Lower values are rejected with "must be = 10 seconds (prevents API rate limiting)", and decimals are dropped. The interval doesn't relax quote freshness: quotes must be at most 5 seconds old whenever the Bot decides, whatever the interval. With bucket.select: all, the list of matched buckets is refreshed about every half interval. Fees The edge checks subtract an estimate of each leg's taker fee. The estimates never change what a venue actually charges. Built in fee estimates Leg Estimate per order Rounding Example, 1 contract Kalshi 0.07 × contracts × p × (1 − p). The rate is 0.035 when the ticker starts with INX or NASDAQ100 Up to the cent At 0.42: $0.0171 → $0.02 Polymarket The market's live fee rate × min(p, 1 − p) × shares None Depends on the market's rate Polymarket US 0.0695 × contracts × p × (1 − p). The rate is 0.10 on Table Tennis markets Nearest cent (ties to even) At 0.53: $0.01731 → $0.02 Here p is the price paid. The Kalshi half rate depends only on the ticker's text before the first hyphen: a ticker such as KXINXU … starts with KX, so it uses 0.07. The Polymarket US estimate uses the taker rates in effect since October 19, 2026: 0.0695 on most markets and 0.10 on Table Tennis markets. The Bot reads each market's details from Polymarket US to tell which rate applies, and uses the market's own published rate when that is higher. It checks again every 5 minutes; if the check fails, the Bot doesn't trade that loop. Polymarket's rate is looked up for each token and reused for up to 5 minutes. If the lookup fails, the Bot doesn't trade that loop. Fee overrides fees replaces the estimate for one or both legs. a is the Kalshi leg and b is the leg B venue. flat_bps (either leg): fee = flat_bps ÷ 10,000 × price × contracts. It isn't rounded. fee_rate_bps (leg B): fee = fee_rate_bps ÷ 10,000 × min(p, 1 − p) × shares. On Polymarket it replaces the live lookup. On Polymarket US it replaces the published formula with this different formula, not just a different rate. fees.a.fee_rate_bps is rejected. It's an input to the Polymarket fee formula, and leg A is always Kalshi. Use fees.a.flat_bps, or leave fees.a out for the built in Kalshi estimate. Set at most one key per leg: both gives "set flat_bps or fee_rate_bps, not both". Negative values are rejected. Write unquoted whole numbers: a quoted "5" is rejected, and so is a decimal such as 2.5. fees and each leg must be blocks of keys: fees: 5 is rejected. 0 counts: flat_bps: 0 assumes that leg is free, and on Polymarket it skips the live lookup. An empty or null leg (a: {} or a: ) means no override. Keys other than a and b, and unknown keys inside a leg, are ignored. Studio's strategy preview shows the fee source for leg B only. A fees.a override is still used even though the preview doesn't list it. Overrides feed the choice between the two lock pairs, every min_net_edge_bps check, the directional check, and the custom fields fee_a, fee_b and net_edge_bps. Warning: An estimate below the real fee makes the edge check optimistic, so a filled lock can earn less than min_net_edge_bps, or lose. Flat overrides aren't rounded, so even a high rate can come in under the rounded real fee at low prices. Kalshi charges $0.01 for 1 contract at 0.10, while flat_bps: 700 estimates $0.007.53:Tbaf,Arbitrage Buckets This page covers the bucket block of an arbitrage strategy (platform: arbitrage). It applies to one setup only: a Kalshi series_ticker on leg A with a rolling daily Polymarket US leg B, set up as shown in Polymarket US leg B. Every bucket key is also listed in All arbitrage parameters. Daily markets such as a city's high temperature are listed as several bucket markets per day: 74 °F or below, 75 to 76 °F, and so on. With a rolling daily Polymarket US leg and a Kalshi series_ticker, the Bot pairs buckets that settle on exactly the same range and trades one pair at a time. The bucket block chooses which pair. bucket is allowed only when venues.b.platform is polymarket_us with a recurring selector. Anywhere else, even bucket: {} is rejected. A bare bucket: line with no value counts as leaving it out. Leaving it out is the same as select: all. How matching works: 1. The Bot finds the current Polymarket US event (see Polymarket US leg B) and the Kalshi series' markets that close within 120 seconds of it. 2. It reads each market's settlement range as whole numbers, both ends included. Polymarket US … gte77lt78f and Kalshi "between 77 and 78" both cover 77 to 78. Polymarket US … lt75f and Kalshi "less than 75" cover 74 and below. Polymarket US … gte83f and Kalshi "greater than 82" cover 83 and above. 3. Buckets with exactly the same range on both venues become pairs. A bucket without an exact match is dropped. 4. bucket.select picks the pair to trade. That pair still has to pass every lock check, including min_net_edge_bps after fees. bucket.select Value Picks When it picks again all (default) The pair with the best gross edge, before fees, from each market's listed best bid and ask, in the better direction. If no pair has those quotes yet, the pair whose Kalshi midpoint is closest to 50¢ Every loop, so it can switch buckets nearest_even_odds The pair whose Kalshi midpoint is closest to 50¢ Once per daily event max_volume The pair with the most Kalshi plus Polymarket US volume Once per daily event pinned_bounds Only the pair whose range equals bucket.bounds Once per daily event. If that bucket has no pair, every loop skips Case doesn't matter. Other values are rejected with "unknown bucket selector". all ranks pairs by gross edge from listed quotes, not by net edge after fees. The chosen pair is then checked against min_net_edge_bps using the live order books. bucket.bounds With select: pinned_bounds, set gte, lte or both, as whole numbers that match the bucket's range exactly, both ends included: Bucket bounds 77 to 78 °F (… gte77lt78f) gte: 77, lte: 78 83 °F or above (… gte83f) gte: 83 74 °F or below (… lt75f) lte: 74, not 75 bounds with any other select is rejected ("bounds is only used with select: pinned_bounds"), and so is pinned_bounds without either bound. A decimal such as 77.5, or a gte above lte, saves but never matches a bucket, so every loop skips. A bucket block with a fixed leg B is rejected:54:T243c,Arbitrage Examples and Validation Errors This page collects complete arbitrage strategies (platform: arbitrage) for both venue pairs: fixed and rolling hedged locks, inverted labels, daily temperature buckets, inline selectors with a Kalshi fee override, a directional buy and custom rules. It ends with common validation errors and what to change for each. For what each key does, see All arbitrage parameters. Example strategies Each example below passes Studio's checks. Markets, IDs and numbers are illustrative placeholders. Ask Studio's search for real markets, and choose your own limits. Fixed markets on Kalshi and Polymarket US One pinned market on each venue, with matching labels. Each loop the Bot prices Kalshi YES + Polymarket US NO and Kalshi NO + Polymarket US YES at 1 contract, and locks the better one when its net edge is at least 150 bps. With the deploy limits Studio pre fills (1 contract and $1 per order), each lock is 1 contract; see risk.max_position_usdc. With 150 bps of slippage, Kalshi's limit gains a cent only for asks of about 34¢ and up. If the hedge fails, fills a different quantity or takes longer than 15 seconds, the Bot halts. Being fixed market, it stays halted. When the Kalshi market closes, the Bot stops. Rolling 15 minute crypto on Kalshi and Polymarket Both legs roll every window, paired by close time; see Rolling markets. Each window, the Bot pairs the Kalshi market that closes within 120 seconds of the current Polymarket market. If no Kalshi market matches, or more than one does, the loop skips. The Polymarket leg always goes first, and each lock must reach the market minimum, usually 5 shares. The deploy dialog raises Max contracts per order, Max dollars per order and Max open contracts to at least 5 for this pair. Polymarket fees use the market's live rate. If it can't be read, the loop skips. accept_resolution_source_mismatch: true records that you accept that the two venues settle on different price sources. It doesn't change how the Bot trades. Inverted labels on Polymarket Kalshi's "Celtics win" against Polymarket's "Will the Lakers beat the Celtics?". Kalshi YES is Polymarket NO, so each lock is YES + YES or NO + NO. See mapping.a_yes_equals. The IDs are placeholders. Studio's Polymarket search returns the real condition ID, token IDs, price step and minimum order size. The yes token is "Lakers win", so the locks are Kalshi YES + Polymarket YES and Kalshi NO + Polymarket NO. Exactly one leg of each pays $1. min_order_size: "5" is the size every lock must reach. tick_size is used only if the live price step can't be read. Daily temperature buckets on Kalshi and Polymarket US A rolling daily pair that trades only the 77 to 78 °F bucket each day, pinned with bucket.bounds. Each day the Bot finds the current temp nychigh YYYY MM DD event, matches its buckets to the Kalshi markets that close within 120 seconds, and trades only the pair covering 77 to 78. If that bucket has no matching pair that day, every loop skips. Remove the bucket block (or use select: all) to let the Bot re screen every matched bucket each loop instead. Inline selectors and a Kalshi fee override The compact selector form, a bucket chosen by even odds, and a flat Kalshi fee estimate. nearest_even_odds picks the matched bucket whose Kalshi midpoint is closest to 50¢, once per daily event, and stays on it until the event rolls. flat_bps: 700 estimates Kalshi's fee as 0.07 × price per contract, unrounded. At 1 contract that's above the built in estimate from about 30¢ up, and can be below it at lower prices. Polymarket US has no 5 share minimum, so the pre filled deploy limits of 1 contract and $1 per order are enough to trade. Directional buy on one venue Not arbitrage: a single leg buy on Polymarket US. See directional for how it decides to buy. The Bot buys 1 YES contract when the ask is at or below 0.40 and (0.40 − ask) × 10,000, minus the fee in bps, is at least 200. At 0.36 it buys; at 0.37 it skips. It buys again every 60 seconds while that holds, until it holds 25 YES contracts in that market, then skips and logs "directional buy blocked by max_position". It never sells them. Max open contracts and Max daily notional traded from the deploy dialog can stop it sooner. With the limits Studio pre fills for a $10 budget (10 open contracts, $10 a day), it stops at 10 contracts. max_leg_slippage_bps is left out, so it defaults to 25. Custom rules on a rolling pair Clear orders once a window is nearly decided, pause when the Kalshi balance is low, and lock only when Kalshi YES is cheaper than Polymarket YES. See custom for how rules run. Rules run from the top, and the first match acts and ends the loop. Rule 1 cancels this Bot's resting orders on Kalshi and in the current Polymarket market, never ones you placed by hand. Rule 3 compares two live values with value_field, and checks that the Polymarket fee for 1 contract is at most $0.02. These conditions only decide whether to try. execute_lock still picks the better lock pair itself and applies min_net_edge_bps. Common validation errors These are common messages from Studio's checks on an arbitrage document, and what to change for each. Message What to change version: unsupported arbitrage DSL version 2 (want 1) Use version: 1. platform: arbitrage DSL must set platform: arbitrage Use platform: arbitrage. The pair comes from venues.b.platform. strategy: unknown arbitrage strategy "lock" (want complementary\ directional\ custom) Use one of the three strategies. venues.a.platform: leg A platform must be kalshi Leg A is always Kalshi. venues.b.platform: leg B platform must be polymarket or polymarket_us Use one of the two supported leg B venues. venues.a.market: leg A must set a market selector Add ticker or series_ticker. The same message exists for leg B. venues.a.market: Kalshi arbitrage leg must use either market.ticker or market.series_ticker, not both Keep one. Check for an inline key next to a nested one. venues.b.market: regular Polymarket arbitrage leg must set condition_id, yes_token_id, and no_token_id, … Add all three, or use series_slug or recurring. venues.b.market.neg_risk: negative risk/multi outcome Polymarket markets are not supported for arbitrage Pick a binary market, or remove neg_risk: true. market.recurring.asset: must be one of btc, eth, sol, xrp, doge, hype, or bnb (same for market.recurring.interval) Use a listed asset or interval. On a Polymarket leg B the path has no venues.b. prefix. venues.b.market: Polymarket US arbitrage leg cannot use regular Polymarket condition/token, … Remove the regular Polymarket keys. Use slug or recurring. venues.b.market.recurring.kind: Polymarket US recurring selector requires kind: daily Add kind: daily. venues.b.market.recurring.event_slug_prefix: Polymarket US recurring selector requires event_slug_prefix … Add the event slug without its date, such as temp nychigh. venues.b.market: use either market.slug or market.recurring for Polymarket US, not both Keep one. venues.a.market.series_ticker: recurring Polymarket US leg B requires a rolling Kalshi series_ticker on leg A … Use series_ticker on leg A. venues: leg A rolls with market.series_ticker but regular Polymarket leg B is pinned to one market, … (or the reverse, leg B rolls …) Make both legs roll, or both fixed. See Rolling markets. venues.b.market.min_order_size: must be a positive number Write a number such as 5. mapping.a_yes_equals: must be b_yes or b_no Set a_yes_equals. risk.max_position_usdc: must be 0 Set a per lock budget above 0. loop.interval: must be = 10 seconds (prevents API rate limiting) Use 10 or more. fees.b: set flat_bps or fee_rate_bps, not both Keep one key per leg. fees.a.fee_rate_bps: is a Polymarket fee input and cannot be used on the Kalshi leg A; … Use fees.a.flat_bps, or remove fees.a. risk.min_net_edge_bps: must be a whole number, got 12.5 (any whole number key) Drop the decimals. bucket.bounds.gte: must be finite Write a number, not .nan or .inf. bucket: bucket requires a recurring Polymarket US leg B (market.recurring with kind: daily) Remove bucket, or use a rolling daily Polymarket US leg. bucket.select: unknown bucket selector "best" … Use all, nearest_even_odds, max_volume or pinned_bounds. bucket.bounds: pinned_bounds requires bounds with gte and/or lte … Add bounds.gte, bounds.lte or both. bucket.bounds: bounds is only used with select: pinned_bounds Remove bounds, or use select: pinned_bounds. rules: custom arbitrage strategy requires at least one rule Add a rule, or use complementary. rules[0].when.all[0].field: unknown arbitrage state field "price" Use one of the arbitrage fields. rules[0].action: unknown arbitrage action "buy_yes" Use execute_lock, cancel_all or skip. rules[0].when.all[0].value: must be a number (got 0.5); remove the quotes Write the number without quotes. rules[0].action: buy@a requires explicit side and limit price rule params, … Use execute_lock, cancel_all or skip. risk.accept_resolution_source_mismatch: DSL lists a resolution source mismatch or candidate only caveat; … Studio only. Accept the listed settlement difference in chat, or choose a pair that settles the same way. For how validation works across venues, see the Strategy Reference overview.55:Tfcd,Backtest Strategies Backtesting is how Turbine Studio helps you reject bad ideas before they reach a live runner. It replays a Studio strategy against supported historical data and reports simulated fills, PnL, drawdown, trade count, and execution assumptions. A backtest is not a prediction. It is a structured argument about what would have happened under a specific model and a specific data window. What backtesting answers Backtesting is useful for questions like: Did the strategy trade often enough to evaluate? Did profits depend on one market or one outlier? Did the strategy require unrealistic fills? Did fees or spreads erase the apparent edge? Did drawdown exceed the user's risk tolerance? Did external data improve the rule or just add complexity? Does the strategy still work with smaller position limits? Backtesting is also useful when the answer is no. A rejected idea is a good outcome if it prevents a weak strategy from going live. What Studio models Studio backtests focus on prediction market execution realities: venue market prices where supported, spread aware fills, maker and taker behavior where strategy type supports it, position limits, price bounds, fees where available, market close behavior, external edge data timing, stale data skips, simulated equity curve and trade log. The exact simulation model can vary by venue, market, data availability, and strategy type. Studio surfaces assumptions in the result so you can decide how much weight to give the backtest. Supported data Studio currently uses historical data from: Kalshi, Polymarket where supported, edge data including historic Coinbase data, edge data including National Weather Service data. See Data Sources for details. How to run a backtest 1. Build or open a Studio strategy. 2. Confirm the market selector and risk limits. 3. Ask Studio to backtest. 4. Review summary metrics. 5. Inspect trade count, fills, drawdown, and assumptions. 6. Revise one thing at a time. 7. Backtest again only when the revision has a reason. Example prompt: What to look for Trade count A strategy with too few simulated trades may not have enough evidence. A beautiful result from three trades should be treated as a hypothesis, not a system. Drawdown Drawdown shows how painful the path may have been. A positive PnL with unacceptable drawdown may still be a bad fit. Fill quality If the result depends on perfect entries or thin markets, reduce confidence. Fees and spread Prediction market edges can be small. Fees and spread can turn a good looking signal into a bad live strategy. Data timing Edge data must be available at the time the strategy would have acted. If the rule depends on data that arrives late or is stale, the backtest should show skipped actions or weaker results. Market concentration If one market drove most of the PnL, test whether the thesis generalizes. Using backtests as filters Backtests should help filter ideas: Result Good response Low trade count Narrowly label the result as inconclusive. High PnL, huge drawdown Reduce risk or reject the strategy. Profit disappears after fees Reject or redesign the entry rule. Depends on stale edge data Add stale data pauses or reject. Works only with loose limits Do not deploy without explicit approval. Stable under conservative limits Consider small live deployment. What backtests do not prove Backtests do not guarantee: live fills, future market behavior, continued data availability, venue uptime, execution speed, liquidity, settlement outcomes, profitability. They are one input. Use them alongside strategy reasoning, market knowledge, and conservative live limits. AI agent guidance When reporting a backtest, an AI agent should explain: the strategy tested, the data window, the venue and market scope, the most important assumptions, the key metrics, the weakest part of the result, whether the idea should be rejected, revised, or tested live at small size. Do not summarize a backtest as "good" without naming why. Do not recommend deployment when the result is fragile.56:Te7f,Backtest Data Sources Studio backtests use historical market data and supported edge data to evaluate Studio strategy specs. The goal is to approximate the information and execution conditions a strategy would have faced at the time. Data coverage can vary by venue, market, and time period. Studio should treat unavailable data as a limitation, not as a blank check to assume perfect conditions. Market data Studio currently works with supported historical data from: Source Used for Kalshi Prediction market prices, spreads, timing, fills, and market close behavior where supported. Polymarket Prediction market strategy research where supported by the current Studio surface. Market data helps answer: what price was available, whether a spread was tradable, whether a market was active enough, how a position would have changed over time, whether the market was near close, whether the strategy traded too often or too rarely. Edge data Edge data is external information a strategy can use as a signal. Current edge data includes: Source Typical strategies Historic Coinbase data Crypto linked prediction markets, momentum, mean reversion, cross signal strategies. National Weather Service data Weather linked prediction markets, forecast fades, observation based rules. Edge data helps test whether an external signal would have improved the strategy at the time, not just in hindsight. Coinbase edge data Coinbase historical data is useful when the prediction market references crypto prices or crypto linked outcomes. Example strategy ideas: BTC spot moves faster than the prediction market price. ETH price momentum confirms an event market drift. SOL volatility rises while the contract price remains stale. A market overreacts to a short term move and mean reverts. Example prompt: National Weather Service edge data NWS data is useful for weather linked contracts and strategies that depend on forecasts, alerts, or observations. Example strategy ideas: fade markets that overreact to forecast noise, compare forecast implied probability to market price, avoid trading when weather data is stale, stop opening risk as the observation window approaches resolution. Example prompt: Data timing A serious backtest should avoid future information. Edge data should be evaluated as if the strategy only knew what was available at that timestamp. AI agents should watch for these issues: using a final outcome as if it were known early, using revised data without acknowledging revision risk, ignoring data staleness, treating an unavailable signal as zero, comparing markets that were not open at the same time, assuming liquidity that did not exist. Missing or stale data When data is missing or stale, conservative behavior is preferred: skip the entry, keep existing risk bounded, cancel maker quotes if the signal is required, flag the backtest as limited, ask the human whether to use a simpler rule. Do not fill gaps with optimistic assumptions. Choosing data for a strategy Use market data when the strategy is based on book behavior: spread capture, liquidity filters, price momentum, price mean reversion, close time behavior. Use edge data when the thesis depends on outside information: crypto price movement, weather forecast disagreement, scheduled observation updates, external volatility. Use both when the strategy needs a market reaction and an external signal: AI agent checklist Before running or reporting a backtest, confirm: the market data source is supported, the edge data source is supported, the data window is meaningful, the strategy does not rely on future information, stale data causes skips or pauses, missing data is disclosed, the result is not presented as a guarantee.57:Tdf6,Reading Backtest Results A backtest result is a decision aid. It should help you decide whether to reject, revise, or cautiously run a Studio strategy. Do not read the largest PnL number first and stop there. The useful information is usually in the assumptions, trade distribution, drawdown, and fill behavior. Summary metrics Common metrics include: Metric How to read it PnL Simulated profit or loss under the backtest model. Useful, but easy to overfit. ROI PnL relative to configured strategy risk. Compare only against similar risk settings. Sharpe Return consistency under the modeled path. Weak if sample size is small. Max drawdown Largest peak to trough loss. Often more important than headline PnL. Win rate Percent of profitable trades. Can be misleading without average win/loss size. Trade count Evidence level. Too few trades means the result is fragile. Fees Modeled cost of trading. Edges that vanish after fees are weak. Fill count How often the strategy would actually act. Equity curve The equity curve shows the path, not just the ending. Look for: one sudden jump that explains the whole result, long flat periods with no trades, repeated drawdowns, late recovery that hides poor earlier behavior, performance concentrated near market close, changes after a data source begins or ends. An attractive final number with an ugly path may still be a bad strategy. Trade log The trade log helps explain the result. Review: entry timestamp, exit timestamp, side, simulated fill price, size, reason for entry, reason for exit, fees, PnL per trade, market or event identifier. If the winning trades all come from one market or one short period, reduce confidence. Execution assumptions Every backtest has assumptions. Studio should make them visible enough for a user or AI agent to reason about the result. Important assumptions include: how fills are modeled, whether the strategy takes liquidity or posts maker quotes, how fees are applied, how stale edge data is handled, whether partial fills are modeled, how market close is treated, how unavailable data is skipped, which markets were eligible. When assumptions are strict, a backtest may be conservative. When assumptions are loose, the result needs more skepticism. Comparing revisions When you revise a strategy, change one major variable at a time: exposure cap, spread limit, entry threshold, exit timing, data source, market selector, stop opening window. Then compare: Did PnL improve because the thesis improved? Did PnL improve only because risk increased? Did drawdown fall? Did trade count become too low? Did fees become a smaller share of returns? Did the strategy become more or less dependent on one event? Red flags Reject or revise when: the strategy needs huge exposure to work, PnL disappears with realistic spreads, one trade explains the whole result, drawdown exceeds the user's tolerance, the rule depends on stale data, the strategy opens risk too close to resolution, the backtest has too few trades, performance improves only after removing guardrails. What a good report says A good AI generated backtest report should sound like this: Not this: Decision labels Use clear labels: Label Meaning Reject The idea is weak, unsupported, or too fragile. Revise The thesis may be useful, but the current rules need work. Paper follow Watch live markets without placing risk. Run small Deploy with conservative limits and monitoring. Scale later Only after live behavior matches the backtest over time. Backtesting is valuable because it slows down bad ideas. Treat that as a feature.58:T136b,Run Strategies Run is the part of Studio that moves an approved strategy from a draft into live execution. Studio keeps the experience simple, but the deployment model is designed to be permissionless and user controlled. Turbine partnered with Locus (YCF25) so every user gets one private runner per venue family that hosts their Bots. A Bot is one running instance of a strategy, live or paper; the runner executes it with the user's credentials and limits. Turbine helps build, test, and deploy the strategy, but the runner is the live execution environment. See Locus deployments for how Bots, runners, and caps fit together. When to run Only run a strategy after: the strategy matches the user's intent, the risk limits are explicit, the strategy has been backtested where data is available, the user understands the backtest assumptions, live credentials are ready, monitoring and pause behavior are understood. If the backtest is inconclusive, use smaller limits or keep the strategy in review. Deployment flow 1. Approve the strategy Review the strategy type, market selector, edge data, entries, exits, and risk limits. 2. Review backtest Make sure the result is strong enough to justify a small live test. 3. Prepare credentials Connect the venue credentials required for the strategy. Credentials are intended for the user's runner, not for a shared Turbine trading account. 4. Deploy to Locus Studio provisions the venue's private runner through Locus if it does not exist yet, then deploys the strategy onto it as a Bot. 5. Start execution The Bot begins evaluating the strategy on its configured loop, as its own process beside any sibling Bots already on that runner. 6. Monitor Watch status, logs, fills, exposure, and any pause conditions. 7. Revise or stop If live behavior diverges from the thesis, stop that Bot or deploy an updated strategy to it. Its siblings on the same runner keep running, as long as that runner is healthy and current. Permissionless by design The run experience should feel like a normal Studio deployment, but the execution path is not a custodial black box. Key properties: each user gets a private runner per venue family, which hosts that family's Bots — Kalshi events, Kalshi Perps, Polymarket US, Turbine, and Kalshi + Polymarket US arbitrage share one runner, while Polymarket has its own because it executes from a different region, the runner belongs to the user, not to any one Bot, credentials are scoped to that runner, strategy limits travel with the deployment, the user can stop or revise any Bot they are running, the approved strategy remains the readable source of truth. This model lets Studio stay easy to use while preserving a user controlled execution boundary. The browser is optional. See Run a strategy programmatically to export your wallet, compile a public library strategy by slug, and send wallet signed code directly to your Locus runner without Turbine's deploy API. What goes live Live deployment should preserve the same behavior tested in the backtest: market selector, strategy rules, loop cadence, risk limits, edge data requirements, stale data handling, stop conditions, credential scope. If any of these change, run another backtest when possible and make the difference explicit. Good live defaults For a first deployment: start with smaller exposure than the maximum you would tolerate, avoid wide spreads, avoid final minute entries unless the strategy is specifically designed for close behavior, pause on stale data, keep logs enabled, monitor early fills, avoid scaling until live behavior matches the thesis. Updating a running strategy When you revise a strategy that already has a Bot running: 1. keep the running Bot bounded, or stop it, 2. update the strategy, 3. backtest the changed behavior if supported, 4. deploy the new version — the Run button reads Update Bot 2 for the selected Bot and pushes the new code to it in place, keeping its Bot label, while Deploy as new Bot starts a second, independent Bot from the same strategy, 5. confirm the Bot is running the expected version, 6. monitor the first live actions. Avoid stacking multiple untested changes into one deployment. How many Bots you may run at once is a plan entitlement — Starter 1, Basic 3, Pro 5 — counted across every venue and including paper Bots. That cap only blocks starting a new Bot; updating a Bot you already run is never refused for being at the cap. AI agent guidance AI agents should not deploy casually. A good deployment response should include: the exact strategy version or summary, the risk limits that will be live, the backtest result that justified deployment, the target Bot and its runner, and whether the deploy updates that Bot or starts a new one, the pause or stop condition, the statement that live trading can lose money. If the user says "run it" before a backtest, the agent should confirm whether they want to skip testing. The safer default is to backtest first.59:T364c,Locus Deployments Turbine partnered with Locus (YCF25) to give each Studio user private servers for strategy execution. The result is a deployment flow that feels simple in the browser while preserving a permissionless execution model. What Locus provides Locus provides the compute environment where your runners live. A runner is where an approved strategy evaluates markets, reads the configured data sources, and submits venue actions using your credentials. From the user's perspective: Studio builds the strategy, Studio helps backtest the strategy, Studio deploys the strategy as a Bot, Locus hosts one private runner per venue family for each user, each runner executes that family's bots as isolated processes. A venue family is the set of venues one runner trades. Kalshi events, Kalshi Perps, Polymarket US, Turbine, and Kalshi + Polymarket US arbitrage all run on your Kalshi runner. Polymarket has a runner of its own because it executes from a different region. The words Studio uses Term Meaning Strategy The code of a trading idea in a Studio chat. It has no running state of its own. Bot One running instance of a Strategy on one venue, live or paper. Deploying starts a Bot; stopping ends it. Runner Your private execution host for one venue family. It hosts that family's Bots, each isolated from the others. Bot cap How many Bots your plan lets you run at once, across all venues, paper Bots included. Runner capacity The engineering limit on how many Bots a single runner can host. Bot label The name a Bot gets when it deploys — "Bot 2". Labels are never reused. The same Strategy can run as two Bots at once; each keeps its own orders, fills, and results. Why private runners matter A runner hosts isolated Bots. Your live execution never shares a process with another user, and inside a runner each Bot runs as its own process: users do not need to share a pooled trading process, live credentials are scoped to your runner, deploying, updating, or stopping one Bot leaves its siblings running, as long as the runner is healthy and current, a Bot that crashes is retried in place: the runner restarts only that Bot's process, never a sibling's, runner state is easier to reason about. The product should feel easy, but the boundary matters: Turbine Studio is the build and control surface; the runner is the execution surface. Studio is not required to push code. The runner also accepts a code payload signed by its authorized wallet directly at /code; see Run a strategy programmatically for a complete Python example. How many Bots you can run The Bot cap is a plan entitlement, counted across every venue and including paper Bots: Starter 1, Basic 3, Pro 5. The sidebar header shows where you stand — "Running 2 / 3". At the cap, the next deploy is refused: Studio names the limit it hit, and the tier that raises it when there is a higher one. Going over the cap — after a plan change, say — never stops a Bot that is already running. It also never blocks an update to a Bot you already run; the cap only stands between you and a new Bot. Runner capacity is a separate limit on how many Bots one runner can host: five today, the same as the Pro cap. A runner's capacity is shared by its whole venue family. If you ever hit that limit instead of your cap, stop a Bot on that runner or deploy on the other runner (a Polymarket runner exists only where Polymarket is available to you). Running several Bots Deploy from a Strategy chat as usual. When that Strategy already has a Bot running, you get two actions: Update Bot 2 — the Run button takes the selected Bot's label — pushes the new code to that Bot in place: same Bot label, same run. Deploy as new Bot starts a second, independent Bot from the same Strategy. An update reaches only its own Bot as long as that venue's runner is healthy and on the current version. If the runner is out of date, the update is refused and queued rather than pushed; upgrade the runner from the runner panel to let it through. If the runner cannot be reached at all — or you start a new Bot on an out of date one — the deploy falls back to rebuilding the runner, which restarts every Bot on it once. Balance and margin on a venue are shared by every Bot on that venue's runner, so several Bots there draw on one pot of money. Size them together, not as if each had the account to itself. The same goes for the money figure each Bot reports. "Account equity change (since this Bot started)" — in the terminal header, the Analytics tab, and the copilot's summary — is the whole account's equity minus the balance captured when that Bot started, not the Bot's own P&L. Deposits, withdrawals, your manual trades, and every sibling Bot on the runner move it, so five Bots on one runner show five readings of one account that differ only by their start times. There is no per Bot P&L on Kalshi event markets: a Bot's fills are tagged with its identity, but most of an event Bot's P&L is realised at settlement, which is not a fill and carries no Bot tag. To judge one Bot, read its own fills and positions in the Analytics tab and its Orders and Fills filter, not the equity figure. Telling your Bots apart Every Bot carries its label wherever it appears: the Running list gives each Bot a line with its label, Strategy name, venue, Live or Paper, and uptime; the dashboard's copy of that list adds the short hash of the code the Bot is running and when it was deployed, the terminal is titled "Bot 2 · Dip Reverter" and shows that Bot's log lines only — the Bot chips above it switch which Bot you are watching, Orders and Fills default to the Bot you are looking at; switch the filter to All to see sibling Bots' rows, each labelled "Bot 2 · Dip Reverter", alongside your own manual trades, the Analytics tab's Open Orders and Trade History tables use the same filter and the same labels, so a Bot that has never traded shows no trades, not its siblings'; an older run's order that no running Bot claims stays in view as "Untracked bot order". Each Bot's orders and fills carry its identity, so two Bots running the same Strategy stay distinguishable. Stopping a Bot Stopping a Bot ends its run. On its own it sells nothing: open positions stay on your venue account until you deal with them. Resting orders stay too — except on Kalshi Perps, where the Bot cancels its own open orders as it shuts down. Selling is opt in and Kalshi only. A live Kalshi Bot's stop dialog offers a "sell all Kalshi positions" checkbox; on any other venue the request is refused. When you do tick it, the sale cancels resting orders first, and what it sells depends on what else is running: stopping the only Bot on that venue's runner sells the whole account, including positions you opened by hand, stopping one Bot beside siblings sells only that Bot's own net position and leaves siblings and manual positions alone. If the shared account can only reduce by less than the Bot's ledger claims — other exposure points the other way, or part of the position settled or you closed part of it by hand — Studio lists the shortfall with the reason account_cannot_reduce. A position the account no longer holds at all, because it settled or you closed it by hand, produces no row: there is nothing left to sell. A per Bot sale that fails is finished, not pending: the Bot's resting orders have already been cancelled, except any the report lists as a failure, and its runner slot is gone, so the stop cannot be retried. Close whatever the report lists as remaining yourself, on the venue. To flatten a whole venue on purpose — every Bot plus manual positions — use stop all on that venue instead of stopping Bots one at a time. Its sell is the same opt in, and Kalshi only in the same way. Arbitrage Bots Two arbitrage Bots never share a Polymarket market. If a market is already traded by an arbitrage Bot on that runner, Studio refuses a second Bot on it; point the new Bot at a different market. That refusal only looks at one runner, while your Polymarket position in a market is shared by every Bot on the account — so keeping arbitrage Bots on different runners off one market is left to you. Adding a second arbitrage Bot to a runner also demotes the first from the shared order namespace it had to itself. Its own orders already carried a per Bot prefix, so nothing changes about how it places them; what changes is what it still owns. The fills it made under the shared prefix drop out of its P&L immediately — bounded to the fills of its current run, which is all its P&L counts — and from its next restart it stops cancelling the orders it left resting under that prefix, as does every other Bot. Cancel those resting orders before you add the second arbitrage Bot. Kalshi Perpetuals Bots Perps Bots run on your Kalshi runner, beside your Kalshi event market Bots: they share its capacity and its stop all. That stop all ends every Bot on the runner, and the sale it offers covers event market positions only — perps positions stay open. Several Perps Bots can run on one runner, and deploying one puts it on a single margin account, cross margined with every other Perps Bot there: each Bot tracks its own Position — the net of its own fills — and its TP/SL closes only that Position, the exchange's account level position and margin belong to the account, not to any one Bot, a close is clamped to what the shared account can actually reduce, so a Bot whose Position the account no longer carries closes nothing; it says so once in its terminal and stays quiet until the account's position changes, liquidation is account wide: one Bot's losses can liquidate what the others are holding. Watch margin usage across the venue as a whole, not per Bot. Upgrading a runner Turbine updates the runner from time to time. Two paths reach a new build, with different effects on running Bots. An update that ships as a git push rebuilds the runner in place: the Bots running on it are picked back up and keep their labels, but per Bot state files written on the runner's disk do not survive the rebuild. The explicit Upgrade or Update Software action in Studio stops all live and paper Bots on that runner and provisions a fresh, idle runner. Exchange credentials are preserved. Redeploy the Bots you want to run after the update; their strategy code is not compiled or copied during the upgrade. Stopping Bots does not automatically close exchange positions. What that empty disk costs after an in place rebuild, or when you redeploy after an explicit upgrade: a halted arbitrage Bot forgets that it halted and resumes with the unhedged leg it stopped on — resolve the halt and close that leg before upgrading, a Kalshi Perps Bot rebuilds its Position before it trades again: its order prefix survives the move, so it finds its own orders in Kalshi's order history and adds up their fills, however old. It places neither entries nor exits until that is done, usually within its first check. If Kalshi's order history no longer lists an order, or the fills can't be read, the Bot logs Position rebuild incomplete and trades on what it could rebuild, so check each Perps Bot's Position after an upgrade and flatten anything no Bot claims, Polymarket fills from before the upgrade lose their Bot attribution and drop out of that Bot's P&L, each Bot's risk state — the running loss its max loss limit counts, and any risk halt it recorded — starts over from the limits it was deployed with. Paper sessions and starting balances survive an in place rebuild through Studio. An explicit upgrade ends active paper sessions; redeploy a paper Bot to start it again. Anything else that has to outlive a rebuild lives in Studio, not on the runner. Manage your server in Locus If you'd like to manage your server directly through Locus's interface, Locus's Build docs show how. They cover projects, services, deployments, variables, domains, and other infrastructure without Turbine's interface. Deployment lifecycle 1. Provision Studio creates the venue's runner the first time you deploy there. 2. Configure The runner receives the Bot's code, environment, and required credentials. 3. Start The runner starts the Bot as its own process, beside any siblings already running. 4. Observe Studio surfaces each Bot's status, logs, orders, and fills. 5. Update A revised Strategy can update the Bot in place, or deploy as a new Bot beside it. 6. Stop Stop a Bot when the thesis breaks, limits are reached, or you want to revise behavior. Credential boundary Venue credentials should be treated as live trading secrets. The intended model is: the user supplies the credentials needed for their strategy, credentials are passed to the user's runner and used by every Bot on it, credentials are not a Turbine owned trading account, credentials should not be exposed in docs, logs, prompts, or screenshots, users remain responsible for the permissions and safety of their venue accounts. AI agents should never ask a user to paste credentials into a public prompt or doc. Use the Studio credential flow. Permissionless execution The deployment flow is designed so a user can run strategies without asking Turbine to manually operate a bot for them. The user approves the strategy, provides credentials, deploys it as a Bot on their runner, and can stop or revise it. This does not remove trading risk. It changes who controls execution. What stays private These docs expose the public wallet signing contract needed for portability, but not private deployment internals or Turbine's control plane architecture. AI agents do not need those internals to use Studio safely. The public model is enough: Studio drafts and tests strategies. Locus hosts one private runner per venue family for each user. Runners execute each Bot as its own process with user scoped configuration. Users monitor and control every Bot they are running.5a:Tc2a,Run a strategy programmatically Turbine strategies are portable. Turbine provides a public strategy library and a compiler; your wallet authorizes your Locus runner. You can use the site as a frontend, leave it entirely, and still run the same strategy from your own program. The ownership boundary is simple: 1. Your program asks Turbine's public API for canonical Python for a public strategy slug. 2. Your program hashes and signs that exact Python locally with your wallet. 3. Your program sends the signed code directly to your Locus runner's /code endpoint. 4. The runner verifies that the signer is its authorized wallet before accepting the code. The third step does not call Turbine's API. There is no Turbine deploy token, deploy authorization, or control plane approval in this flow. Turbine does not place trades on your behalf: the wallet owned Locus account executes the code you authorize. If you'd also like to manage the server itself through Locus's interface, Locus's Build docs show how. They cover projects, services, deployments, variables, domains, and related infrastructure. Exporting a private key gives you full control of that wallet. Privy presents the key in its secure export flow; Turbine does not receive or store it. Keep it in a secrets manager, never send it to Turbine, and never commit it to a repository. Choose a public strategy slug Open a strategy in the public library and copy its slug from the URL. For example, a strategy at /backtest/weather edge has the slug weather edge. Canonical Python is available without account authorization: Only strategies that qualify for the public library can be compiled through this endpoint. The response is Python, with ETag and X Turbine Code SHA256 headers so a client can verify the exact bytes it received. Arbitrary private DSL cannot be submitted to this endpoint. Run the Python client Download the complete example below, install its two dependencies, and provide secrets through environment variables: TURBINE_API_URL is optional and defaults to https://api.turbinefi.com. The script checks /auth info before signing, refuses a runner assigned to another wallet, validates the compiler's SHA 256 header, and limits the downloaded code to the runner's 2 MB request limit. The signed BotCodeUpdate uses Polygon chain ID 137, an empty environment, an empty intent ID, and a zero authorization nonce. The final request is sent to LOCUS_RUNNER_URL/code with the exact compiled Python. It intentionally has no Turbine bearer token and does not use a Turbine code push endpoint. What the wallet authorizes The signature authorizes one code payload for the runner configured with that wallet. It is not a general permission for Turbine to trade, move funds, or deploy future code. If you change even one byte of Python, its hash changes and the old signature no longer verifies. Venue credentials and risk settings are separate from this example. The program leaves the runner environment unchanged. Review the strategy, configure the runner's venue credentials and limits, and monitor the account directly before using real funds.5b:Tbb6,Monitoring Live Strategies Monitoring is how you keep a running Bot connected to its original thesis. A backtest can justify a small live trial, but live markets can change faster than a strategy document. Studio should be used to watch status, exposure, fills, logs, and stop conditions after deployment. Watch these per Bot: a venue's runner can host several Bots at once, each Bot's terminal shows only that Bot's log lines, and its orders and fills default to that Bot. See Locus deployments. What to monitor Area Why it matters Runner status Confirms the venue's private runner is online and that its Bots are evaluating their strategies. Current exposure Shows how much risk the strategy has opened. Open orders Reveals stale quotes, stuck orders, or unexpected maker behavior. Fills Shows whether live fills resemble the backtest assumptions. Logs Explains strategy decisions, skips, pauses, and errors. Edge data freshness Prevents strategies from trading on stale signals. Market spread Wide spreads can erase expected edge. Drawdown Live losses can invalidate the original risk plan. Healthy behavior A healthy live Bot should: stay within max position, respect price bounds, skip entries when data is stale, avoid unsupported markets, cancel orders when conditions change, log why it entered or skipped, stop opening risk near configured close windows, behave similarly to the backtested version. Reasons to pause Pause or stop when: fills are materially worse than modeled, spreads are wider than expected, edge data is missing or stale, the market structure changed, the strategy reaches drawdown limits, the Bot is repeatedly erroring, the user no longer believes the thesis, the strategy behaves differently from the approved rules. Pausing is not failure. It is part of running automated strategies responsibly. Comparing live to backtest Ask: Are live fills near the simulated fill assumptions? Is trade frequency similar? Are skipped entries expected? Are fees and spreads in the expected range? Is drawdown inside the modeled range? Is edge data arriving with acceptable freshness? If live behavior diverges, revise the strategy or stop that Bot. Updating monitoring rules Monitoring rules should be explicit in the strategy or deployment settings when possible: alert on stale data, alert on runner downtime, alert on max exposure, alert on drawdown, alert on repeated order failures, alert on unexpected market selector changes. AI agents should explain why an alert matters and what action the human should consider. Incident response When something looks wrong: 1. pause opening new risk, 2. inspect open orders and exposure, 3. read recent logs, 4. compare live behavior to the approved strategy, 5. close or reduce risk if the user chooses, 6. revise and backtest before redeploying. Do not respond to a live issue by making the strategy more aggressive. AI agent reporting format A useful monitoring summary: An unsafe summary: Monitoring should keep the human in control.5c:Tc28,Risk & Limits Turbine Studio helps users build and run automated prediction market strategies, but automation does not remove risk. It can make risk happen faster. Every strategy should have explicit limits before it is backtested or deployed. Core risks Prediction market strategies can lose money because of: bad signals, overfitting, poor fills, wide spreads, partial fills, fees, stale data, market close behavior, venue downtime, unexpected settlement, account or credential issues, strategy bugs, live behavior diverging from a backtest. Studio is designed to make these risks easier to inspect, not to eliminate them. Required limits Every serious strategy should define: Limit Purpose Max position Caps total exposure. Max order size Prevents one action from taking too much risk. Price floor Avoids buying too high or selling too low depending on side. Price ceiling Avoids entering at extreme prices. Spread limit Avoids markets where execution cost is too high. Stop opening window Prevents new risk too close to market close. Stale data policy Prevents trading when required signals are old or missing. Pause condition Stops opening new risk when the thesis breaks. Backtest risk Backtests can mislead when: the sample is small, the best result comes from one market, the rules were repeatedly tuned to the same window, fill assumptions are too generous, future data leaks into the simulation, fees are ignored, live liquidity is thinner than history suggests. Use backtests to reject weak strategies. Be slower to use them as proof. Live deployment risk Live strategies can behave differently because: markets move faster than the strategy loop, fills are not guaranteed, posted orders can become stale, data can arrive late, venue rules or access can change, the user's credentials or account permissions can fail, the runner can lose network connectivity. This is why first deployments should be small. AI agent rules AI agents using Studio should follow these rules: Do not call a strategy risk free. Do not promise profit. Do not remove risk limits without approval. Do not deploy before backtesting unless the user explicitly chooses to skip testing. Do not hide weak backtest assumptions. Do not treat missing data as favorable. Do not increase position size as a default optimization. Do not ask users to paste credentials into normal chat. Conservative defaults When a user has not specified limits, a conservative draft should: use small position sizes, avoid wide spreads, avoid late entries, require fresh data, include clear exits, pause on repeated errors, prefer fewer markets over broad exposure. The AI should state that these are defaults and ask the user to confirm before deployment. Human approval points Studio should keep humans involved at important points: approving the strategy, accepting assumptions, moving from backtest to live, increasing exposure, adding a new market family, changing credential scope, restarting after a pause. The point of Studio is not to make risk invisible. The point is to make strategy automation understandable enough that risk can be bounded.5d:T3af8,Turbine MCP Quickstart Copy and paste this to your agent: Turbine MCP lets a compatible AI client work with your Turbine Studio account. The AI can inspect your strategies, trading logs, live status, research, and backtests; ask Turbine's account aware AI for context; and help you make supported changes. Use this remote MCP server URL: You do not need to create or copy an API key. Turbine MCP uses OAuth, so authentication happens on turbinefi.com and your Turbine password or login code never passes through the AI client. Connect your AI client Your client must support remote Streamable HTTP MCP servers and either browser redirect OAuth or OAuth device authorization. 1. Open your AI client's MCP or integrations settings. 2. Add a remote MCP server using https://api.turbinefi.com/api/v1/mcp. 3. When your browser opens Turbine, sign in with the same method you normally use on turbinefi.com. 4. Review the client name, origin, and requested access on the Accept connection page. 5. Select Accept connection. Return to the AI client when Turbine tells you the connection is approved. The client can then discover the available tools. Any registered Turbine account can connect. The connection receives the full MCP tool catalog, while every request still follows the account's current membership limits, ownership rules, and usage limits. Only approve a connection when you recognize the client name and origin. A connected client can read your Turbine account and request supported account changes. Local AI clients Local applications such as desktop clients and CLIs use OAuth 2.1 authorization code flow with PKCE. The client starts a temporary callback listener on 127.0.0.1 (localhost), opens the Turbine Accept connection page in your browser, and receives the authorization result through that local callback after you approve it. The localhost callback works because the browser and the OAuth client run on the same computer. Keep the client running until the browser returns to it. Server side agents Server side agents such as Meta's Muse run on a remote VM, so a loopback browser callback cannot reach them. Use the OAuth 2.0 Device Authorization Grant (RFC 8628) instead. Endpoints Purpose URL Protected resource discovery https://api.turbinefi.com/.well known/oauth protected resource/api/v1/mcp OAuth discovery https://api.turbinefi.com/.well known/oauth authorization server Dynamic client registration (DCR) https://api.turbinefi.com/oauth/register Device authorization https://api.turbinefi.com/oauth/device/authorize Token https://api.turbinefi.com/oauth/token Revocation https://api.turbinefi.com/oauth/revoke Streamable HTTP MCP https://api.turbinefi.com/api/v1/mcp Hosted / remote AI clients 1. Register a confidential client with DCR and save the returned client_id and client_secret. 2. Request a device code with HTTP Basic authentication and resource=https://api.turbinefi.com/api/v1/mcp. 3. Show the user both verification_uri_complete and user_code. The complete URL pre fills the code; the user signs in, reviews the client, and approves it. 4. Poll the token endpoint no faster than the returned interval, again using HTTP Basic authentication and the same resource. Continue after authorization_pending; after slow_down, add five seconds to the polling interval. Stop on access_denied, expired_token, or invalid_grant. Device and user codes expire after ten minutes. A successful device code exchange consumes the code, so a later request returns invalid_grant. The following example requires curl and jq. Run it in Bash, then approve the displayed URL in your browser: The access token expires after 900 seconds. Refresh tokens expire after 30 days and rotate on every refresh: store the new refresh token and discard the old one. Reusing an old refresh token revokes its entire token family and OAuth grant. Each rotated refresh token receives a new 30 day lifetime. Connection failures during token polling api.turbinefi.com can intermittently drop a connection mid response. Retry connection failures, HTTP 429, and HTTP 5xx responses with backoff. When polling returns HTTP 200 but the connection fails, inspect and parse the saved body first; it may contain the issued token even if the HTTP client reported an error. Never blindly retry the same device code after an ambiguous HTTP 200. The server may have consumed the single use code and committed the tokens before the connection dropped; a retry then returns terminal invalid_grant. If the saved body does not contain a complete token response, stop and begin a new device flow. What the AI can do Turbine MCP exposes owner scoped tools for the same Studio workflow you use on the website. Area Examples Account and setup Check membership, usage limits, runner state, and missing setup requirements. Strategies and sessions List and inspect strategies and Studio sessions; create, copy, rename, update, or delete supported strategies. Backtests and research Start backtests or research, check job progress, read results, and inspect completed research reports. Live and paper activity Inspect deployments, diagnostics, runtime logs, PnL, trades, fills, equity, and run history. Trading journal Read journal runs, events, contracts, and sampled account state. Turbine AI Use ask_turbine for account aware explanations and recommendations grounded in the user's current Turbine state. Deployment control Unavailable through MCP. Use Turbine Studio to manage deployments; MCP can read status and activity. Results are scoped to the authenticated account. Connecting MCP does not give one user access to another user's strategies, runners, logs, or credentials. Finding account resources To browse the published library at /studio/strategies, use list_strategy_library. Set sort to recent for newest first, or to name, pnl, roi, sharpe, win_rate, stars, or market; use order for ascending or descending results. Search with query, and filter by platform, category, asset, interval, engine, or market. Set group to family to discover strategy families, then pass a returned family_key as family to compare its variants. Follow next_cursor with the same filters and sorting to continue the list. get_library_strategy accepts an entry's ID or slug as strategy_id and returns its rules, parameters, and available backtest details. Library IDs can also be used with copy_shared_strategy. To browse the published Deep Research collection at /studio/research, use list_public_research_reports. It returns completed reports newest completed first, with next_cursor for older results. Pass a returned slug to get_public_research_report to read the analysis and strategy comparisons. These public library tools are separate from your owned strategy and research tools below. Start with list_strategies to find your saved Studio strategies. Pass query to search their names, titles, and strategy labels. Search returns the newest matching results up to the requested limit and sets truncated when more exist. Without query, use next_cursor to page through strategies. The returned id is the strategy_id for get_strategy; current Studio deployments also use that session ID as bot_id for deployment and analytics reads. Use list_sessions when you need the Studio conversation history; it also supports next_cursor. Use list_journal_runs to find recent live and paper runs, then pass run_id to the journal detail, event, contract, and sample tools. Use list_research_reports to find a report_id for get_research_report. Research list entries are compact summaries; follow next_cursor for older reports. ask_turbine receives a bounded snapshot of the account's recent sessions, journal runs, and research reports alongside any resource IDs you supply. For a question about older activity or a specific strategy, first find its ID with the list tools and pass that ID to ask_turbine. A nonempty next_cursor means the snapshot is incomplete; continue paging before making an account wide claim. Each write operation has its own preview and execution tools, published with its complete schema before any tool calls: Preview tool Required preview inputs Execution tool preview_create_strategy platform, message create_strategy preview_update_strategy session_id, message update_strategy preview_copy_shared_strategy Published strategy_id copy_shared_strategy preview_copy_session Owned session_id copy_session preview_delete_strategy Owned session_id delete_strategy preview_start_backtest session_id start_backtest preview_create_research market_type, thesis, base_dsl create_research preview_start_research report_id start_research preview_cancel_research report_id cancel_research Backtest previews also accept period_days, end_time (RFC3339), starting_balance, simulated starting_account, and simulated runtime_limits. Research drafts support Kalshi crypto or weather markets, with optional venue: "kalshi" and sweep_dims containing numeric param/values grids. Strategy creation also accepts an optional arbitrage_leg_b_platform. Consult each published tool schema for its fields and constraints. Each execution tool accepts only a confirmation_token from its matching preview. The preview persists a short lived receipt without applying the proposed operation. Use its token only after the user approves that exact preview. Flexible requests You can ask an agent to browse newly published strategies, explain a research report, inspect one running bot, compare parameter variants, create a draft, or inspect deployment activity. Combine these capabilities in a natural language request when useful. MCP supplies a capability guide at connection time so the agent can choose the tools relevant to your request; there is no required sequence of strategy creation and backtesting for every task. For a request to improve parameters, the agent should compare proposed changes with the current baseline and explain the available evidence. Deployment changes are unavailable through MCP, including changes to paper deployments. Existing deployment previews and confirmation tokens cannot execute deployment actions. Recurring notifications require a schedule configured in the AI client. Preview and confirm changes Reading data does not require confirmation. Consequential changes use the same two step safety model as the Turbine interface: 1. The AI calls the specific preview tool, such as preview_delete_strategy, with its exact parameters. 2. Turbine validates the request and returns a human readable summary, warnings, affected resource versions, and a short lived confirmation token. The receipt is saved, but the proposed operation has not run. 3. The AI shows you that preview and asks for explicit confirmation. 4. Only after you confirm may the AI call the matching execution tool, such as delete_strategy, with the one time confirmation_token. Confirmation tokens expire after five minutes and work only for the connection that created them. Tokens are bound to the specific operation and stored parameters. A token presented to a different operation is rejected without being consumed. Consumed confirmations cannot be reused. Deployment confirmation tokens issued before deployment controls were disabled are also rejected. If the protected resource changes between preview and confirmation, Turbine rejects the confirmation and requires a fresh preview. Low risk session renames are immediate and idempotent; they do not change trading state. Deployment controls MCP supports strategy drafts, backtests, research, and reads of existing deployment activity. It does not support deploy, update, switch, stop, recover, redeploy, or cancel deployment actions, in either live or paper mode. These actions are absent from the advertised action schema and rejected by the server, including confirmations issued before deployment controls were disabled. Manage deployments directly in Turbine Studio. Editing a saved draft through MCP does not send an update to a running bot. Runner credentials never pass through MCP. Membership and plan limits MCP does not bypass Turbine membership rules. Bot caps, feature availability, rate limits, and other account limits are checked against the current plan when a tool runs. If a tool requires a different plan, the response includes a plan_limit_reached error and a direct link to Membership. Changing plans does not require reconnecting the AI client. The next tool call uses the updated account limits. Tasks that stay on turbinefi.com For security and direct user control, MCP does not accept payment details, venue credentials, deposits, or withdrawal instructions. Configure venue credentials and manage deployments directly on turbinefi.com. Do not paste API keys, private keys, seed phrases, passwords, or other secrets into an MCP conversation. Task Where to complete it Choose or change a membership Open Membership, select a plan, and complete checkout. Configure a runner or venue credentials Open Turbine Studio, open the strategy's deploy panel, choose the venue, and complete the guided setup. Deposit funds Open the strategy's deploy panel in Turbine Studio, follow the venue specific funding instructions, verify the destination, and wait for the balance to appear. Withdraw funds Use Turbine Studio to identify the active venue account or runner, then review and submit the withdrawal through the linked venue or account interface. When one of these prerequisites blocks an operation, the MCP response includes a stable error such as credentials_required or plan_limit_reached, plus the exact steps, destination URL, and tool to retry afterward. The AI should explain those steps but cannot complete the website only action for you. Reconnecting an AI client does not enable deployment controls. Deployment actions remain unavailable through MCP. Manage connected clients Open Membership and find AI connections to review each connected client's name, origin, connection date, and last use time. Select Revoke to disconnect a client. Revocation takes effect immediately: existing access and refresh tokens stop working, and the client must complete the browser authorization flow again before it can access Turbine. Troubleshooting The browser does not open Confirm that the AI client supports OAuth for remote MCP servers, then remove the incomplete connection and add the Turbine MCP URL again. The connection request expired Return to the AI client and start a new connection. Authorization requests are short lived and cannot be reopened after they expire. A tool says setup is required Follow the steps and URL returned in the error. Complete the membership, runner, funding, or credential task on turbinefi.com, then ask the AI to retry the named tool. A confirmation failed Ask the AI for a new preview. The earlier token may have expired, already been used, or become invalid because the strategy or deployment changed after the preview. A previously connected client receives an authentication error Check AI connections on the Membership page. If the connection was revoked, reconnect from the AI client and approve the new browser request.5e:Tec2,AI Agent Guide This page is the compact operating guide for AI agents using Turbine Studio. Studio's public surface is the strategy workflow: 1. build a strategy, 2. backtest the strategy, 3. run it as a Bot on the user's private Locus runner for that venue, 4. monitor and revise. Do not rely on internal architecture knowledge. Do not invent hidden APIs. Use the Studio surface and keep the user's risk visible. Agent objective Help the user turn a prediction market thesis into a bounded, testable, inspectable strategy. The correct output is not "a bot that makes money." The correct output is a clear strategy draft, a candid backtest interpretation, and a conservative deployment recommendation when justified. Build behavior When the user asks to build: 1. Restate the thesis. 2. Identify the market or market family. 3. Ask for missing risk limits or choose conservative defaults. 4. Draft a Studio ready strategy. 5. Explain the important fields. 6. Recommend a backtest before deployment. Never skip straight from a vague thesis to live deployment. Check field names, allowed values, and venue support against the Strategy Reference before proposing a draft. Backtest behavior When the user asks to backtest: 1. Confirm the strategy version. 2. Use supported historical market data and edge data. 3. Report assumptions. 4. Report metrics. 5. Identify the weakest part of the result. 6. Recommend reject, revise, paper follow, or run small. Good phrasing: Bad phrasing: Run behavior When the user asks to run: 1. Confirm they want live execution. 2. Confirm the strategy and risk limits. 3. Confirm the backtest result or explicitly note if they are skipping it. 4. Use the Studio credential flow. 5. Deploy as a Bot on the user's private Locus runner for that venue. 6. Monitor the first live behavior. Deploying a strategy that already has a Bot updates that Bot in place, and the plan's Bot cap never blocks that; Deploy as new Bot starts a second Bot beside it, up to that cap (Starter 1, Basic 3, Pro 5, across all venues and including paper Bots). Other Bots on that runner keep running either way, as long as that runner is healthy and current: a deploy onto a runner Turbine cannot reach, or a new Bot on an out of date one, rebuilds the runner and restarts every Bot on it once, while an in place update onto an out of date runner is queued until you upgrade the runner. See Locus deployments. If the user asks for larger exposure, treat that as a separate approval point. Supported concepts to mention Agents can safely mention: Turbine Studio, structured strategy drafts, build, backtest, run, Kalshi market data, Polymarket market data where supported, Coinbase historical edge data, National Weather Service edge data, modeled fills and fees, Locus (YCF25) private per venue family runners, Bots, Bot labels, and the plan's Bot cap, user scoped credentials, risk limits, monitoring and pause behavior. Agents should avoid: internal service names, database details, private deployment implementation, undocumented endpoints, claims about guaranteed fills, claims about guaranteed returns, credential handling outside the Studio flow. Useful prompts Build: Backtest: Revise: Run: Monitor: Final checklist before live deployment Before recommending deployment, confirm: the user approved the strategy, the strategy is readable, max exposure is explicit, exit rules exist, stale data behavior exists when edge data is used, the backtest has been reviewed, live credentials are handled through Studio, the deployment target is the user's runner, and it is clear whether the deploy updates an existing Bot or starts a new one, the user understands live trading can lose money. If any item is missing, say what is missing and do not pretend the strategy is ready.e:["$","$1","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/3f7sd4nq-tt3m.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/1ia1gxupn26v6.js","async":true,"nonce":"$undefined"}]],["$","div",null,{"className":"docs-module__hZJeFq__docsLayout","children":[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"BreadcrumbList\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https://www.turbinefi.com\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Documentation\",\"item\":\"https://www.turbinefi.com/docs\"}]}"}}],["$","$L17",null,{"searchIndex":[{"title":"Overview","slug":"overview","href":"/docs/overview","content":"$18"},{"title":"Build","slug":"build","href":"/docs/build","content":"$19"},{"title":"Strategy Specs","slug":"strategy-specs","href":"/docs/build/strategy-specs","content":"$1a"},{"title":"Prompting Studio","slug":"prompting","href":"/docs/build/prompting","content":"$1b"},{"title":"Studio Challenges","slug":"challenges","href":"/docs/build/challenges","content":"$1c"},{"title":"Strategy Reference","slug":"strategy-reference","href":"/docs/strategy-reference","content":"$1d"},{"title":"Kalshi","slug":"kalshi","href":"/docs/strategy-reference/kalshi","content":"$1e"},{"title":"Market Selection","slug":"market-selection","href":"/docs/strategy-reference/kalshi/market-selection","content":"$1f"},{"title":"Risk & Loop","slug":"risk","href":"/docs/strategy-reference/kalshi/risk","content":"$20"},{"title":"Windows & Schedules","slug":"schedules","href":"/docs/strategy-reference/kalshi/schedules","content":"$21"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/kalshi/examples","content":"$22"},{"title":"Rejected Strategies","slug":"rejected-strategies","href":"/docs/strategy-reference/kalshi/rejected-strategies","content":"$23"},{"title":"Polymarket","slug":"polymarket","href":"/docs/strategy-reference/polymarket","content":"$24"},{"title":"Market Selection","slug":"market-selection","href":"/docs/strategy-reference/polymarket/market-selection","content":"$25"},{"title":"Units & Risk","slug":"units-and-risk","href":"/docs/strategy-reference/polymarket/units-and-risk","content":"$26"},{"title":"Built-ins & Custom Rules","slug":"strategies","href":"/docs/strategy-reference/polymarket/strategies","content":"$27"},{"title":"Windows, Paper Runs & Fees","slug":"windows-backtests-fees","href":"/docs/strategy-reference/polymarket/windows-backtests-fees","content":"$28"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/polymarket/examples","content":"$29"},{"title":"Polymarket US","slug":"polymarket-us","href":"/docs/strategy-reference/polymarket-us","content":"$2a"},{"title":"Markets & Execution","slug":"markets-and-execution","href":"/docs/strategy-reference/polymarket-us/markets-and-execution","content":"$2b"},{"title":"Strategies & Edge Data","slug":"strategies","href":"/docs/strategy-reference/polymarket-us/strategies","content":"$2c"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/polymarket-us/examples","content":"$2d"},{"title":"Built-in Strategies","slug":"built-in-strategies","href":"/docs/strategy-reference/built-in-strategies","content":"$2e"},{"title":"Risk, Loop & Other Blocks","slug":"shared-settings","href":"/docs/strategy-reference/built-in-strategies/shared-settings","content":"$2f"},{"title":"spread_capture","slug":"spread-capture","href":"/docs/strategy-reference/built-in-strategies/spread-capture","content":"$30"},{"title":"mean_reversion","slug":"mean-reversion","href":"/docs/strategy-reference/built-in-strategies/mean-reversion","content":"$31"},{"title":"panic_fade","slug":"panic-fade","href":"/docs/strategy-reference/built-in-strategies/panic-fade","content":"$32"},{"title":"observation_momentum","slug":"observation-momentum","href":"/docs/strategy-reference/built-in-strategies/observation-momentum","content":"$33"},{"title":"pre_announcement_drift","slug":"pre-announcement-drift","href":"/docs/strategy-reference/built-in-strategies/pre-announcement-drift","content":"$34"},{"title":"Custom Rules","slug":"custom-rules","href":"/docs/strategy-reference/custom-rules","content":"$35"},{"title":"Conditions & Missing Data","slug":"conditions","href":"/docs/strategy-reference/custom-rules/conditions","content":"$36"},{"title":"Field Catalog","slug":"fields","href":"/docs/strategy-reference/custom-rules/fields","content":"$37"},{"title":"Actions","slug":"actions","href":"/docs/strategy-reference/custom-rules/actions","content":"$38"},{"title":"Validation","slug":"validation","href":"/docs/strategy-reference/custom-rules/validation","content":"$39"},{"title":"Exit Checks","slug":"exit-checks","href":"/docs/strategy-reference/custom-rules/exit-checks","content":"$3a"},{"title":"Entry Checks","slug":"entry-checks","href":"/docs/strategy-reference/custom-rules/entry-checks","content":"$3b"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/custom-rules/examples","content":"$3c"},{"title":"Advanced Kalshi Rules","slug":"kalshi-advanced-rules","href":"/docs/strategy-reference/kalshi-advanced-rules","content":"$3d"},{"title":"Composite Orders & Price Cap","slug":"composite-orders","href":"/docs/strategy-reference/kalshi-advanced-rules/composite-orders","content":"$3e"},{"title":"Per-Fill Exits","slug":"per-fill-exits","href":"/docs/strategy-reference/kalshi-advanced-rules/per-fill-exits","content":"$3f"},{"title":"Rule-Level Schedules","slug":"rule-schedules","href":"/docs/strategy-reference/kalshi-advanced-rules/rule-schedules","content":"$40"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/kalshi-advanced-rules/examples","content":"$41"},{"title":"Edge Data","slug":"edge-data","href":"/docs/strategy-reference/edge-data","content":"$42"},{"title":"Declaring & Reading","slug":"declaring","href":"/docs/strategy-reference/edge-data/declaring","content":"$43"},{"title":"Coinbase","slug":"coinbase","href":"/docs/strategy-reference/edge-data/coinbase","content":"$44"},{"title":"NWS Weather","slug":"nws","href":"/docs/strategy-reference/edge-data/nws","content":"$45"},{"title":"Economic Calendar","slug":"economic-calendar","href":"/docs/strategy-reference/edge-data/economic-calendar","content":"$46"},{"title":"Derived Metrics","slug":"derived-metrics","href":"/docs/strategy-reference/edge-data/derived-metrics","content":"$47"},{"title":"Examples & Errors","slug":"examples","href":"/docs/strategy-reference/edge-data/examples","content":"$48"},{"title":"Kalshi Perps","slug":"kalshi-perps","href":"/docs/strategy-reference/kalshi-perps","content":"$49"},{"title":"Markets & Execution","slug":"markets-and-execution","href":"/docs/strategy-reference/kalshi-perps/markets-and-execution","content":"$4a"},{"title":"Sizing & Risk","slug":"sizing-and-risk","href":"/docs/strategy-reference/kalshi-perps/sizing-and-risk","content":"$4b"},{"title":"Archetypes","slug":"archetypes","href":"/docs/strategy-reference/kalshi-perps/archetypes","content":"$4c"},{"title":"Custom Strategies","slug":"custom-strategies","href":"/docs/strategy-reference/kalshi-perps/custom-strategies","content":"$4d"},{"title":"Examples","slug":"examples","href":"/docs/strategy-reference/kalshi-perps/examples","content":"$4e"},{"title":"Arbitrage","slug":"arbitrage","href":"/docs/strategy-reference/arbitrage","content":"$4f"},{"title":"Venues & Selectors","slug":"venues","href":"/docs/strategy-reference/arbitrage/venues","content":"$50"},{"title":"Mapping & Strategies","slug":"strategies","href":"/docs/strategy-reference/arbitrage/strategies","content":"$51"},{"title":"Risk & Fees","slug":"risk-and-fees","href":"/docs/strategy-reference/arbitrage/risk-and-fees","content":"$52"},{"title":"Buckets","slug":"buckets","href":"/docs/strategy-reference/arbitrage/buckets","content":"$53"},{"title":"Examples & Errors","slug":"examples","href":"/docs/strategy-reference/arbitrage/examples","content":"$54"},{"title":"Backtest","slug":"backtest","href":"/docs/backtest","content":"$55"},{"title":"Data Sources","slug":"data","href":"/docs/backtest/data","content":"$56"},{"title":"Reading Results","slug":"results","href":"/docs/backtest/results","content":"$57"},{"title":"Run","slug":"run","href":"/docs/run","content":"$58"},{"title":"Locus Deployments","slug":"locus","href":"/docs/run/locus","content":"$59"},{"title":"Programmatic Runner","slug":"programmatic","href":"/docs/run/programmatic","content":"$5a"},{"title":"Monitoring","slug":"monitoring","href":"/docs/run/monitoring","content":"$5b"},{"title":"Risk & Limits","slug":"risk","href":"/docs/risk","content":"$5c"},{"title":"MCP","slug":"mcp","href":"/docs/mcp","content":"$5d"},{"title":"AI Agent Guide","slug":"ai-agents","href":"/docs/ai-agents","content":"$5e"},{"title":"Brand Kit","slug":"brand-kit","href":"/docs/brand-kit","content":"Turbine Brand Kit logo usage mascot examples icon examples social graphics templates font typography Plus Jakarta Sans colors logo guide graphics clear space contrast avatar Discord X header post templates."}]}],"$L5f"]}]]}] f:["$","$1","c",{"children":[null,["$","$L60",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L61",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}] 10:["$","$1","c",{"children":["$L62",[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0-97cwhccsuli.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/1n87-csk84ixk.js","async":true,"nonce":"$undefined"}],["$","script","script-1",{"src":"/_next/static/immutable/chunks/42sqovkhwzqps.js","async":true,"nonce":"$undefined"}],["$","script","script-2",{"src":"/_next/static/immutable/chunks/1z1praf2-9tle.js","async":true,"nonce":"$undefined"}],["$","script","script-3",{"src":"/_next/static/immutable/chunks/2_thcx99a3k35.js","async":true,"nonce":"$undefined"}],["$","script","script-4",{"src":"/_next/static/immutable/chunks/22pivn53pnfx7.js","async":true,"nonce":"$undefined"}]],["$","$L63",null,{"children":["$","$64",null,{"name":"Next.MetadataOutlet","children":"$@65"}]}]]}] 12:["$","$1","h",{"children":[null,["$","$L66",null,{"children":"$L67"}],["$","div",null,{"hidden":true,"children":["$","$L68",null,{"children":["$","$64",null,{"name":"Next.Metadata","children":"$L69"}]}]}],["$","meta",null,{"name":"next-size-adjust","content":""}]]}] 14:["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0ix6vujw7ee1a.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 15:["$","link","1",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/3me7fmtkc4wgw.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 16:["$","link","2",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0xtm7vbl319or.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 11:C 5f:["$","main",null,{"className":"docs-module__hZJeFq__docsMain","children":["$","div",null,{"className":"docs-module__hZJeFq__docsContent","children":["$","$L60",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L61",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]}]}] 62:E{"digest":"NEXT_REDIRECT;replace;/docs/run/locus;307;"} 67:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]] 6a:I[27201,["/_next/static/immutable/chunks/28nhklyuaf-g_.js","/_next/static/immutable/chunks/1yr3mpizubdvt.js","/_next/static/immutable/chunks/1ht-qf-q4tks1.js","/_next/static/immutable/chunks/3gou7gbjwpu4x.js","/_next/static/immutable/chunks/1ljrubmtyjhqb.js","/_next/static/immutable/chunks/0pohkvjkyx0ml.js","/_next/static/immutable/chunks/0e_plrpk4tuu-.js","/_next/static/immutable/chunks/3egobnolkwoyy.js","/_next/static/immutable/chunks/104stqri_an_6.js","/_next/static/immutable/chunks/264ys8ckb-e39.js","/_next/static/immutable/chunks/3w61dvn9304yj.js","/_next/static/immutable/chunks/3j5_5chqftfmo.js","/_next/static/immutable/chunks/11i8qm_sgbq8n.js","/_next/static/immutable/chunks/0thm4tqk_qgt_.js","/_next/static/immutable/chunks/0-qougt1b7wim.js","/_next/static/immutable/chunks/213orb6ur0xf3.js","/_next/static/immutable/chunks/3074gp72li5ko.js","/_next/static/immutable/chunks/03p--y4p0cs1h.js","/_next/static/immutable/chunks/08v4mbtubzcep.js","/_next/static/immutable/chunks/0-1ua4s2j6o1y.js","/_next/static/immutable/chunks/0whkp1tczizef.js","/_next/static/immutable/chunks/28czqhyf77eaq.js","/_next/static/immutable/chunks/0neaff_kbqqhr.js","/_next/static/immutable/chunks/2szcaahnw0h2j.js","/_next/static/immutable/chunks/2bgdwqwdgngll.js","/_next/static/immutable/chunks/0lb7bv83rp9fc.js","/_next/static/immutable/chunks/3tkxe7g_791uv.js","/_next/static/immutable/chunks/3adhiv949a347.js"],"IconMark"] 65:null 69:[["$","title","0",{"children":"Documentation | Turbine"}],["$","meta","1",{"name":"description","content":"Technical documentation for Turbine prediction markets."}],["$","meta","2",{"name":"author","content":"Turbine"}],["$","meta","3",{"name":"keywords","content":"AI trading bots,AI agents,automated trading,prediction markets,Kalshi,trading bot builder,no-code trading,Turbine Studio"}],["$","meta","4",{"name":"creator","content":"Turbine"}],["$","meta","5",{"name":"publisher","content":"Turbine"}],["$","link","6",{"rel":"canonical","href":"https://www.turbinefi.com/docs/api/authentication"}],["$","meta","7",{"property":"og:title","content":"Documentation | Turbine"}],["$","meta","8",{"property":"og:description","content":"Technical documentation for Turbine prediction markets."}],["$","meta","9",{"property":"og:image","content":"https://www.turbinefi.com/api/og/default"}],["$","meta","10",{"property":"og:image:width","content":"1200"}],["$","meta","11",{"property":"og:image:height","content":"630"}],["$","meta","12",{"property":"og:image:alt","content":"Documentation | Turbine"}],["$","meta","13",{"property":"og:type","content":"article"}],["$","meta","14",{"name":"twitter:card","content":"summary_large_image"}],["$","meta","15",{"name":"twitter:title","content":"Documentation | Turbine"}],["$","meta","16",{"name":"twitter:description","content":"Technical documentation for Turbine prediction markets."}],["$","meta","17",{"name":"twitter:image","content":"https://www.turbinefi.com/api/og/default"}],["$","meta","18",{"name":"twitter:image:alt","content":"Documentation | Turbine"}],["$","link","19",{"rel":"icon","href":"/icon.png","type":"image/png","sizes":"1024x1024"}],["$","link","20",{"rel":"apple-touch-icon","href":"/apple-icon.png"}],["$","$L6a","21",{}]] 6b:T8ef,(function(){var KEY="turbine:chunk-load-recovery:v1";var PARAM="_turbine_chunk_reload";var TTL=60000;var MSG=/(ChunkLoadError|Loading chunk [\w-]+ failed|Failed to load chunk|error loading dynamically imported module|Importing a module script failed)/i;var CHUNK=/\/_next\/static\/chunks\/[^"'<> )]+\.js/i;function text(v,d){if(v==null||d>3)return "";if(typeof v==="string")return v;if(typeof v!=="object"&&typeof v!=="function")return "";var out=[];try{if(v.name)out.push(v.name);if(v.message)out.push(v.message);if(v.stack)out.push(v.stack);if(v.filename)out.push(v.filename);var t=v.target||v.srcElement;if(t&&(t.src||t.href))out.push(t.src||t.href);if(v.cause)out.push(text(v.cause,d+1));if(v.error)out.push(text(v.error,d+1));if(v.reason)out.push(text(v.reason,d+1));}catch(e){}return out.join(" ")}function resource(v){try{var t=v&&(v.target||v.srcElement);return t&&(t.src||t.href)||""}catch(e){return ""}}function isChunkFailure(v){var s=text(v,0);return MSG.test(s)||CHUNK.test(resource(v))}function pathKey(){return window.location.pathname||"/"}function shouldReload(prev,path,now){if(!prev)return true;try{var p=JSON.parse(prev);if(p.path!==path)return true;if(typeof p.ts!=="number")return true;return now-p.ts>TTL}catch(e){return true}}function cleanRetryParam(){try{var u=new URL(window.location.href);if(!u.searchParams.has(PARAM))return;u.searchParams.delete(PARAM);window.history.replaceState(window.history.state,"",u.pathname+u.search+u.hash)}catch(e){}}function markHandled(event){try{if(event&&event.preventDefault)event.preventDefault();if(event&&event.stopImmediatePropagation)event.stopImmediatePropagation()}catch(e){}}function recover(event){if(!isChunkFailure(event))return;var now=Date.now();var path=pathKey();try{var prev=window.sessionStorage.getItem(KEY);if(!shouldReload(prev,path,now))return;window.sessionStorage.setItem(KEY,JSON.stringify({path:path,ts:now}))}catch(e){if(window.__turbineChunkReloadAttempted)return;window.__turbineChunkReloadAttempted=true}markHandled(event);try{var u=new URL(window.location.href);u.searchParams.set(PARAM,String(now));window.location.replace(u.toString())}catch(e){window.location.reload()}}cleanRetryParam();window.addEventListener("error",recover,true);window.addEventListener("unhandledrejection",recover)})();2:["$","html",null,{"lang":"en","className":"plus_jakarta_sans_9d7629d1-module__pYs-uW__variable","suppressHydrationWarning":true,"children":[["$","head",null,{"children":[["$","script",null,{"dangerouslySetInnerHTML":{"__html":"(function(){var o=\"\".trim().toLowerCase();var h=location.hostname.toLowerCase();var hs=\"predict.mangrove.io\".split(',').map(function(v){return v.trim().toLowerCase().replace(/\\.$/,'')}).filter(Boolean);document.documentElement.dataset.brand=(o==='mangrove'||(o!=='turbine'&&hs.indexOf(h)>-1))?'mangrove':'turbine';})();"}}],["$","script",null,{"dangerouslySetInnerHTML":{"__html":"$6b"}}],["$","script",null,{"dangerouslySetInnerHTML":{"__html":"(function(){function flush(){try{var q=window.$RB;if(!document.hidden||typeof window.$RV!==\"function\"||!q||!q.length)return;var c=[];for(var i=0;i