KalshiYes, that's the behavior that I'm saying would be interesting to change (but I understand it's a ridiculous request).
Yes, that's the behavior that I'm saying would be interesting to change (but I understand it's a ridiculous request).
VOXindie参与话题 14消息总数 410
该用户的聊天记录定位。
聊天记录
共 410 条，显示第 151-200 条But if I hold a Yes contract, selling liquidates that.
But if I hold a Yes contract, selling liquidates that.
Misunderstanding then. You lose 25c on the yes in that situation IF you sell and IF the market doesn't swing back.
Misunderstanding then. You lose 25c on the yes in that situation IF you sell and IF the market doesn't swing back.
You're talking about selling a yes that "you don't have"?
You're talking about selling a yes that "you don't have"?
Maybe I'm not explaining it well. If I buy Yes at .50 and then market drops it to .25, I can't make any profit off of that. If I could buy both, then when market drops I could sell No for a profit and then hold Yes until it goes back above .50.
Maybe I'm not explaining it well. If I buy Yes at .50 and then market drops it to .25, I can't make any profit off of that. If I could buy both, then when market drops I could sell No for a profit and then hold Yes until it goes back above .50.
Financially yes, but the play is different. If I can only buy Yes at .50, then when market goes down, I can't make a play on that side of the volatility.
Financially yes, but the play is different. If I can only buy Yes at .50, then when market goes down, I can't make a play on that side of the volatility.
I know.
I know.
So you can trade on volatility. Ex: 1) buy Yes at .50 and No at .50 2) market (yes) goes up 3) sell Yes at .75, still holding No at .25 4) market goes down 5) sell No at .75 (or hold until close) You can't play both sides with the current setup.
So you can trade on volatility. Ex: 1) buy Yes at .50 and No at .50 2) market (yes) goes up 3) sell Yes at .75, still holding No at .25 4) market goes down 5) sell No at .75 (or hold until close) You can't play both sides with the current setup.
Where are we supposed to get market title/subtitle from now?
Where are we supposed to get market title/subtitle from now?
I wish the yes/no's were treated as separate so you could hold both sides. I would expect the "reduce only" to be canceled entirely or to fill until the overall position is back to 0 (-10).
I wish the yes/no's were treated as separate so you could hold both sides. I would expect the "reduce only" to be canceled entirely or to fill until the overall position is back to 0 (-10).
ETH 15 minute? Lol
ETH 15 minute? Lol
Jarvis, lose me money.
Jarvis, lose me money.
You could track the intent locally if it's an issue (although more work).
You could track the intent locally if it's an issue (although more work).
lmao I didn't even notice the bottom 👍
lmao I didn't even notice the bottom 👍
If you want something on a loop? Pull Events by series ticker and then iterate over the markets.
If you want something on a loop? Pull Events by series ticker and then iterate over the markets.
lol
lol
Are you region blocked?
Are you region blocked?
^lmao he's mad
^lmao he's mad
https://tenor.com/view/dog-barking-dog-barking-barking-dog-mad-gif-17800282840036492907
https://tenor.com/view/dog-barking-dog-barking-barking-dog-mad-gif-17800282840036492907
basically comes down to glitches in the government's weather tracking tech or some guy with a lighter lol
basically comes down to glitches in the government's weather tracking tech or some guy with a lighter lol
I only gamble on exciting things like the highest temperature in Seattle today.
I only gamble on exciting things like the highest temperature in Seattle today.
~15 years ago I worked for a company that did software for prison systems (VB6 lawl) and 90% of the dev team was 60+ year old former COBOL devs.
~15 years ago I worked for a company that did software for prison systems (VB6 lawl) and 90% of the dev team was 60+ year old former COBOL devs.
the question is whether or not you're older than any of the banking systems you've ever worked on (or adjacent to)
the question is whether or not you're older than any of the banking systems you've ever worked on (or adjacent to)
Not sure how that would be handled though if they're not clocking the batch as a unit on receive.
Not sure how that would be handled though if they're not clocking the batch as a unit on receive.
the api says they would reject the entire batch if it violates 429
the api says they would reject the entire batch if it violates 429
In theory you could validate that by measuring batch response time vs non-batch response time.
In theory you could validate that by measuring batch response time vs non-batch response time.
You're talking about the orders getting counted as they're processed instead of at delivery?
You're talking about the orders getting counted as they're processed instead of at delivery?
Could be solved with some kind of group/seq id on the regular orders. Would probably be okay just firing the API calls in order, but there'd still be risk that they get delivered out of order.
Could be solved with some kind of group/seq id on the regular orders. Would probably be okay just firing the API calls in order, but there'd still be risk that they get delivered out of order.
So the batch order guarantees that the first one in the batch executes first?
So the batch order guarantees that the first one in the batch executes first?
How is that possible? lol
How is that possible? lol
Which would line up with 20x10 = 200 rate limit, no?
Which would line up with 20x10 = 200 rate limit, no?
How many orders are you placing in a batch? lol
How many orders are you placing in a batch? lol
So we just place each order one by one?
So we just place each order one by one?
Are they replacing them with something else?
Are they replacing them with something else?
The docs say there's no limit outside of rate limit. If you're not seeing that behavior, it's either a bug on their end or your end 😛
The docs say there's no limit outside of rate limit. If you're not seeing that behavior, it's either a bug on their end or your end 😛
Don't know what you're asking then lol It states the intended behavior.
Don't know what you're asking then lol It states the intended behavior.
via: https://docs.kalshi.com/api-reference/account/list-non-default-endpoint-costs?playground=open#list-non-default-endpoint-costs
via: https://docs.kalshi.com/api-reference/account/list-non-default-endpoint-costs?playground=open#list-non-default-endpoint-costs
and batch orders are more expensive at the base level ``` { "cost": 20, "method": "POST", "path": "/trade-api/v2/portfolio/orders/batched" } ```
and batch orders are more expensive at the base level ``` { "cost": 20, "method": "POST", "path": "/trade-api/v2/portfolio/orders/batched" } ```
Batch deletes are cheaper: ``` { "cost": 2, "method": "DELETE", "path": "/trade-api/v2/portfolio/events/orders/batched" }, ```
Batch deletes are cheaper: ``` { "cost": 2, "method": "DELETE", "path": "/trade-api/v2/portfolio/events/orders/batched" }, ```
v1 API states `The maximum batch size scales with your tier’s write budget` v2 says the same `The maximum batch size scales with your tier’s write budget`
v1 API states `The maximum batch size scales with your tier’s write budget` v2 says the same `The maximum batch size scales with your tier’s write budget`
Go to BTC hourly or something and batch order YES for $.01 at the lowest market. No one will fill it and you can test your theory however you want.
Go to BTC hourly or something and batch order YES for $.01 at the lowest market. No one will fill it and you can test your theory however you want.
Max I was placing 2 orders per batch via v1 and then v2. Migrated once the token costs made v1 hit rate limits.
Max I was placing 2 orders per batch via v1 and then v2. Migrated once the token costs made v1 hit rate limits.
You think it's allowing them through? Could test it by placing orders no one will take.
You think it's allowing them through? Could test it by placing orders no one will take.
The entire batch would be rejected.
The entire batch would be rejected.
`Batch endpoints don’t save tokens` covers it pretty well: https://docs.kalshi.com/getting_started/rate_limits
`Batch endpoints don’t save tokens` covers it pretty well: https://docs.kalshi.com/getting_started/rate_limits
Yeah, but the "seconds" are grouped into buckets. So if you exceed your total token limit in a single batch I'm assuming it'll either be rejected entirely or will only place the first few until you hit your rate limit.
Yeah, but the "seconds" are grouped into buckets. So if you exceed your total token limit in a single batch I'm assuming it'll either be rejected entirely or will only place the first few until you hit your rate limit.
They'd all apply to the rate limit the moment they hit the server.
They'd all apply to the rate limit the moment they hit the server.
What do you mean seconds?
What do you mean seconds?
each order in the batch counts as much as a single order in a non-batch...so yeah it's pretty much token cost limited
each order in the batch counts as much as a single order in a non-batch...so yeah it's pretty much token cost limited
most profitable bug known to man I guess lol
most profitable bug known to man I guess lol