PolymarketLmao I had back of queue not front of queue in my simulation :/. 🤦♂️
Lmao I had back of queue not front of queue in my simulation :/. 🤦♂️
InDev参与话题 1消息总数 45
该用户的聊天记录定位。
聊天记录
共 45 条，显示第 1-45 条does tick size ever change on crypto markets?
does tick size ever change on crypto markets?
Hmm ok I’m going to check my code. This was supposed to be a quick upper limit to build on, but I just don’t see it. Capturing the spread across l1 should be doable with no simulated latency, and over enough samples. Ok I’m gonna do look again
Hmm ok I’m going to check my code. This was supposed to be a quick upper limit to build on, but I just don’t see it. Capturing the spread across l1 should be doable with no simulated latency, and over enough samples. Ok I’m gonna do look again
Hmm I’ll look again
Hmm I’ll look again
Btc has good/bad weeks, eth is negative everywhere
Btc has good/bad weeks, eth is negative everywhere
As a pie in the sky upper limit
As a pie in the sky upper limit
I was checking quoting l1 with no latency.
I was checking quoting l1 with no latency.
I did a pretty deep analysis on MM the crypto markets and the profit is basically rebates, at best it’s even.
I did a pretty deep analysis on MM the crypto markets and the profit is basically rebates, at best it’s even.
Is anyone actually making money with their bot?
Is anyone actually making money with their bot?
can anyone share their maker cancel latency?
can anyone share their maker cancel latency?
Guys when is a cancel actually mean exposure is over? The api a is in 30ms but what event do I need to wait for?
Guys when is a cancel actually mean exposure is over? The api a is in 30ms but what event do I need to wait for?
Question on cancel semantics: when I cancel a resting order, the API acks in ~30ms. Is the order unmatchable from that ack, or does the cancel process through the matching engine with its own delay? Specifically with the taker order delay on these markets … can a marketable order that was already inside its delay window still match my quote after my cancel was acked? Trying to work out whether cancel-ack is the real end of my exposure.
Question on cancel semantics: when I cancel a resting order, the API acks in ~30ms. Is the order unmatchable from that ack, or does the cancel process through the matching engine with its own delay? Specifically with the taker order delay on these markets … can a marketable order that was already inside its delay window still match my quote after my cancel was acked? Trying to work out whether cancel-ack is the real end of my exposure.
rtds ws feed is back
rtds ws feed is back
10s for safety. or you can just read it after 20s and not jump through the hoops, depends how soon you need it 🙂
10s for safety. or you can just read it after 20s and not jump through the hoops, depends how soon you need it 🙂
what you want is 2 to agree. so if you see the same price AND ts changes (a node restamped the same price) AND >10s passed it's reliable
what you want is 2 to agree. so if you see the same price AND ts changes (a node restamped the same price) AND >10s passed it's reliable
to be safe wait 10s
to be safe wait 10s
after about 5s they converge, because their sample at resolution time IS up to date
after about 5s they converge, because their sample at resolution time IS up to date
there's multiple nodes checking and stamping the price and the ts they sampled at
there's multiple nodes checking and stamping the price and the ts they sampled at
so this is what seems to happen.. when it ticks to a new event their backend node grabs the chainlink price if it gets a valid 'guess' it stamps it with it's ts, if not crypto price returns null
so this is what seems to happen.. when it ticks to a new event their backend node grabs the chainlink price if it gets a valid 'guess' it stamps it with it's ts, if not crypto price returns null
UI just does that ^ in fact it just waits longer
UI just does that ^ in fact it just waits longer
read the price, store the ts, wait for > 10s and ts to change but same price shown
read the price, store the ts, wait for > 10s and ts to change but same price shown
but it does show incorrect price - it seems there's multiple nodes checking chainlink and until they converge it's not acurate
but it does show incorrect price - it seems there's multiple nodes checking chainlink and until they converge it's not acurate
use the crypto-price api
use the crypto-price api
it ticks every second, but there is jitter. sometimes there's 1.2s sometimes 2s before the next tick
it ticks every second, but there is jitter. sometimes there's 1.2s sometimes 2s before the next tick
ok that's fine then, if that websocket one remains it'll do
ok that's fine then, if that websocket one remains it'll do
so there's some lag because it goes via pm - and more jitter but otherwise it's similar resolution and latency right?
so there's some lag because it goes via pm - and more jitter but otherwise it's similar resolution and latency right?
hmm yeah the ts on the rtds websocket feed is actually correct for 'live'
hmm yeah the ts on the rtds websocket feed is actually correct for 'live'
yeah like now lol
yeah like now lol
what about the free rtds websocket one? that's all i need for verification
what about the free rtds websocket one? that's all i need for verification
any eta on the rtds?
any eta on the rtds?
still down
still down
rtds still down?
rtds still down?
hmm weird if its resolved can't you redeem against the resolution tho
hmm weird if its resolved can't you redeem against the resolution tho
no i mean using a 30s delay misses a lot of early buys at a cheap price
no i mean using a 30s delay misses a lot of early buys at a cheap price
hmm ok miss a lot of the market
hmm ok miss a lot of the market
which delay did you use?
which delay did you use?
but if you only get one, you don't know when to assume it's correct
but if you only get one, you don't know when to assume it's correct
did you find any way to know which is the correct price aside from just wait? I mean if you get a wrong one and a right one you're confident it's correct
did you find any way to know which is the correct price aside from just wait? I mean if you get a wrong one and a right one you're confident it's correct
seems like some race on their end
seems like some race on their end
there's no way to distinguish which is which except the right one comes afterwards. sometimes you only get the right one. so you can't just ignore the first one
there's no way to distinguish which is which except the right one comes afterwards. sometimes you only get the right one. so you can't just ignore the first one
did you notice it gives the wrong price first, then the right one?
did you notice it gives the wrong price first, then the right one?
anyone here using the crypto-price endpoint?
anyone here using the crypto-price endpoint?
then it gets updated to a new one
then it gets updated to a new one
hmm did anyone notice there's an incorect price to beat at the start of an event when you call their api?
hmm did anyone notice there's an incorect price to beat at the start of an event when you call their api?
hmm latency seems to have dropped to 300ms?
hmm latency seems to have dropped to 300ms?