SlimMaxOnChain

Driving web3 project growth & innovation |web3 content creator & writer | tier 1 KOL | strategic projects Amb @trondao @BingXofficial @foresoGlobal

[SlimMaxOnChain @SlimMaxOnChain]

𝟭𝟭𝟱 𝗽𝗼𝘀𝘁𝘀 𝗼𝗻 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸, 𝗮𝗻𝗱 𝗵𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝗜 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗹𝗲𝗮𝗿𝗻𝗲𝗱.

When I started, I thought I knew what an oracle was.

Going through the @WinkLink_Oracle docs, the announcements and the chain itself taught me a lot more.

My five biggest takeaways:
➜ 𝗩𝗲𝗿𝗶𝗳𝘆, 𝗱𝗼𝗻'𝘁 𝘁𝗿𝘂𝘀𝘁: the burn, the supply and the 7 nodes can all be checked on-chain
➜ 𝗧𝗵𝗲 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗮𝘀 𝗺𝘂𝗰𝗵 𝗮𝘀 𝘁𝗵𝗲 𝗼𝗿𝗮𝗰𝗹𝗲: freshness checks, decimals() and proxy addresses decide whether good data stays good
➜ 𝗜𝘁'𝘀 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗽𝗿𝗶𝗰𝗲 𝗳𝗲𝗲𝗱𝘀: VRF, AnyAPI and Automation cover randomness, custom data and timing
➜ 𝗧𝗵𝗲 𝗯𝘂𝗿𝗻 𝗶𝘀 𝘁𝗶𝗲𝗱 𝘁𝗼 𝗿𝗲𝘃𝗲𝗻𝘂𝗲: 100% of service revenue buys back WIN, so usage is what drives it
➜ 𝗛𝗼𝗻𝗲𝘀𝘁𝘆 𝗮𝗴𝗲𝘀 𝘄𝗲𝗹𝗹: roadmap goals are goals, notified isn't approved, and I'd rather say so

The next things I'm watching are the December 15 feed deadline and Round 2 data in January 2027.

Thank you to everyone who read, replied and asked good questions along the way.

I'll keep checking the chain and posting what I find.

If you only bookmark one link from this whole campaign, make it the docs:
➜ https://t.co/WBbvwi1DO8

𝗧𝗵𝗮𝗻𝗸𝘀 𝗳𝗼𝗿 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝘄𝗶𝘁𝗵 𝗺𝗲.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗣𝗢𝗩: 𝘆𝗼𝘂𝗿 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁 𝗵𝗮𝘀 𝗯𝗲𝗲𝗻 𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗽𝗿𝗶𝗰𝗲 𝘀𝗶𝗻𝗰𝗲 𝗝𝘂𝗹𝘆 𝟮𝟬𝟮𝟯.

𝗜𝘁 𝗶𝘀𝗻'𝘁 𝗮 𝗰𝗮𝗹𝗺 𝗺𝗮𝗿𝗸𝗲𝘁.

𝗜𝘁'𝘀 𝗮𝗻 𝗼𝗹𝗱 𝗽𝗿𝗼𝘅𝘆 𝗮𝗱𝗱𝗿𝗲𝘀𝘀.

Here's the true story behind the joke.

In June 2023, @WinkLink_Oracle introduced 𝗻𝗲𝘄 𝗽𝗿𝗼𝘅𝘆 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁 𝗮𝗱𝗱𝗿𝗲𝘀𝘀𝗲𝘀 for its price feeds, as part of the OCR upgrade.

The announcement said the old addresses would 𝘀𝘁𝗼𝗽 𝘂𝗽𝗱𝗮𝘁𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗝𝘂𝗹𝘆 𝟭, 𝟮𝟬𝟮𝟯.

Developers were asked to switch their code to the new proxies.

The reason was a good one:
➜ With the new proxies, future upgrades could roll out 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝗰𝗼𝗻𝘀𝘂𝗺𝗶𝗻𝗴 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁𝘀
➜ It's the same proxy design the docs recommend today

So the meme comes with a lesson:
➜ A feed that 𝘀𝘁𝗼𝗽𝘀 𝘂𝗽𝗱𝗮𝘁𝗶𝗻𝗴 doesn't throw an error, it just goes quiet
➜ Your 𝘂𝗽𝗱𝗮𝘁𝗲𝗱𝗔𝘁 check is what notices
➜ The 𝗮𝗻𝗻𝗼𝘂𝗻𝗰𝗲𝗺𝗲𝗻𝘁𝘀 𝗽𝗮𝗴𝗲 is where the warning shows up first

If your stale check has been firing every day since mid-2023, at least it was doing its job.

The original notice is still on the announcements page:
➜ https://t.co/wExM7X1uSo

𝗦𝘁𝗮𝗯𝗹𝗲 𝗽𝗿𝗶𝗰𝗲, 𝗼𝗿 𝘀𝘁𝗮𝗹𝗲 𝗮𝗱𝗱𝗿𝗲𝘀𝘀?

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗡𝗲𝘄 𝘁𝗼 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸? 𝗛𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝘄𝗵𝗼𝗹𝗲 𝘁𝗵𝗶𝗻𝗴 𝗶𝗻 𝟲𝟬 𝘀𝗲𝗰𝗼𝗻𝗱𝘀.

@WinkLink_Oracle calls itself the first comprehensive data services platform of TRON's ecosystem.

It brings outside data to TRON smart contracts, which can't fetch anything on their own.

It runs four services:
➜ 𝗣𝗿𝗶𝗰𝗲 𝗙𝗲𝗲𝗱𝘀: 7 independent nodes, one median price on-chain
➜ 𝗩𝗥𝗙: provably fair random numbers, at 10 WIN per request
➜ 𝗔𝗻𝘆𝗔𝗣𝗜: custom data from almost any API
➜ 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻: contracts that run when conditions are met, checked every 3 seconds

The token is 𝗪𝗜𝗡:
➜ It pays for the network's services and its node rewards
➜ 𝟭𝟬𝟬% 𝗼𝗳 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗿𝗲𝘃𝗲𝗻𝘂𝗲 buys back WIN each quarter, and that WIN is burned
➜ Round 1 burned 𝟲𝟳.𝟯𝟲𝗕 𝗪𝗜𝗡, about 𝟲.𝟳𝟰% of the initial supply

Where it runs:
➜ 𝗧𝗥𝗢𝗡 𝗺𝗮𝗶𝗻𝗻𝗲𝘁 and the 𝗡𝗶𝗹𝗲 𝘁𝗲𝘀𝘁𝗻𝗲𝘁 today

That's it.

Everything above can be checked in the docs or on-chain.

The best place to start is the docs intro:
➜ https://t.co/WBbvwi1DO8

𝗗𝗮𝘁𝗮 𝗶𝗻, 𝗪𝗜𝗡 𝗯𝘂𝗿𝗻𝗲𝗱, 𝗮𝗹𝗹 𝗼𝗻 𝗧𝗥𝗢𝗡.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗧𝗵𝗲 𝗧𝗥𝗢𝗡 𝗼𝗿𝗮𝗰𝗹𝗲 𝗱𝗲𝘃 𝘀𝘁𝗮𝗿𝘁𝗲𝗿 𝗽𝗮𝗰𝗸.

Every dev building with @WinkLink_Oracle ends up with roughly the same kit.

These are the tools the docs name for deploying and testing contracts:
➜ 𝗧𝗿𝗼𝗻𝗦𝗰𝗮𝗻, for reading and calling contracts in the browser
➜ The official 𝘄𝗮𝗹𝗹𝗲𝘁-𝗰𝗹𝗶, for people who live in the terminal
➜ 𝗧𝗿𝗼𝗻 𝗜𝗗𝗘, for writing and deploying in one window
➜ 𝗧𝗿𝗼𝗻𝗕𝗼𝘅, for project-style builds and tests
➜ 𝘁𝗿𝗼𝗻𝘄𝗲𝗯, for scripts and frontends

And here's what the docs quietly assume you'll have:
➜ A 𝗡𝗶𝗹𝗲 𝗳𝗮𝘂𝗰𝗲𝘁 bookmark for test TRX and WIN
➜ A tab open on the 𝗳𝗲𝗲𝗱 𝘁𝗮𝗯𝗹𝗲, because you'll copy proxy addresses from it a lot
➜ A sticky note that says 𝗰𝗮𝗹𝗹 𝗱𝗲𝗰𝗶𝗺𝗮𝗹𝘀()

That last one is my addition, but I'd frame it.

If you're starting today, pick one deploy tool and one script tool, and you're set.

The tool list is in the contract deployment section of the price feed docs:
➜ https://t.co/MtumISecys

𝗙𝗶𝘃𝗲 𝘁𝗼𝗼𝗹𝘀, 𝗼𝗻𝗲 𝗳𝗮𝘂𝗰𝗲𝘁, 𝗼𝗻𝗲 𝘀𝘁𝗶𝗰𝗸𝘆 𝗻𝗼𝘁𝗲.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗧𝘄𝗼 𝗜𝗗𝘀 𝘄𝗮𝗹𝗸 𝗶𝗻𝘁𝗼 𝗮𝗻 𝗔𝗻𝘆𝗔𝗣𝗜 𝗰𝗼𝗻𝘀𝘂𝗺𝗲𝗿 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁.

𝗢𝗻𝗹𝘆 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲𝗺 𝗴𝗲𝘁𝘀 𝗶𝗻.

Here they are:
➜ 𝗧𝗵𝗲 𝗷𝗼𝗯 𝗜𝗗 𝘆𝗼𝘂 𝘄𝗲𝗿𝗲 𝗴𝗶𝘃𝗲𝗻: 8495b310-eb4a-479f-8982-ad6565213449
➜ 𝗧𝗵𝗲 𝗦𝗽𝗲𝗰 𝗜𝗗 𝘆𝗼𝘂𝗿 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁 𝘄𝗮𝗻𝘁𝘀: 0x8495b310eb4a479f8982ad656521344900000000000000000000000000000000

Every AnyAPI dev has stared at those two and wondered if they're the same job.

They are, just dressed differently.

The @WinkLink_Oracle AnyAPI docs carry a warning about exactly this.

To set the Spec ID in your consumer contract:
➜ Take the 𝗲𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗷𝗼𝗯 𝗜𝗗
➜ 𝗥𝗲𝗺𝗼𝘃𝗲 𝘁𝗵𝗲 𝗱𝗮𝘀𝗵𝗲𝘀
➜ 𝗥𝗶𝗴𝗵𝘁-𝗽𝗮𝗱 𝗶𝘁 𝘄𝗶𝘁𝗵 𝘇𝗲𝗿𝗼𝘀 until it fills a bytes32
➜ Write it with 𝟬𝘅 in front, as the docs' example does

Get it wrong and your request won't match the job you meant.

The docs show the padded version for their Nile single word job, so you can compare yours character by character.

It's the least glamorous bug in oracle land, and one of the easiest to avoid.

The warning sits in the Consumer Contract section:
➜ https://t.co/6bKrYcgne4

𝗦𝗮𝗺𝗲 𝗜𝗗, 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗼𝘂𝘁𝗳𝗶𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗢𝗰𝘁𝗼𝗯𝗲𝗿 𝘄𝗮𝘀 𝘁𝗵𝗲 𝗺𝗼𝗻𝘁𝗵 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸'𝘀 𝗯𝘂𝘆𝗯𝗮𝗰𝗸 𝘀𝘁𝗼𝗽𝗽𝗲𝗱 𝗯𝗲𝗶𝗻𝗴 𝗮 𝗽𝗹𝗮𝗻 𝗮𝗻𝗱 𝗯𝗲𝗰𝗮𝗺𝗲 𝗮 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻.

Here's my October recap for @WinkLink_Oracle:
➜ 𝗥𝗼𝘂𝗻𝗱 𝟭 of the WIN Buyback and Burn executed on 𝗢𝗰𝘁𝗼𝗯𝗲𝗿 𝟭𝟵, 𝟮𝟬𝟮𝟲
➜ 𝟲𝟳,𝟯𝟱𝟳,𝟯𝟲𝟰,𝟱𝟭𝟬 𝗪𝗜𝗡 went to TRON's black-hole address, worth about $𝟯.𝟱𝟵𝗠 at the time
➜ Total supply fell to 𝟵𝟮𝟲,𝟯𝟰𝟰,𝟰𝟵𝟰,𝟳𝟯𝟯 𝗪𝗜𝗡, matching the burn to the token
➜ Earlier in the month, Binance's removal of WIN from 𝗠𝗮𝗿𝗴𝗶𝗻 𝗮𝗻𝗱 𝗟𝗼𝗮𝗻𝘀 took effect, with spot trading unaffected

And here's what's next on my calendar:
➜ 𝗗𝗲𝗰𝗲𝗺𝗯𝗲𝗿 𝟭𝟱, 𝟮𝟬𝟮𝟲: the legacy 6-decimal WIN/USD and WIN/TRX feeds stop updating
➜ 𝗝𝗮𝗻𝘂𝗮𝗿𝘆 𝟮𝟬𝟮𝟳: Round 2 burn data is due

If you're a builder, the December date is the one to act on now.

If you're a holder, January is the one to watch.

Either way, both can be checked without trusting anyone.

The Round 1 transaction is here:
➜ https://t.co/cjwF4cZrak

𝗢𝗻𝗲 𝗯𝘂𝗿𝗻 𝗱𝗼𝗻𝗲, 𝗼𝗻𝗲 𝗱𝗲𝗮𝗱𝗹𝗶𝗻𝗲 𝗮𝗻𝗱 𝗼𝗻𝗲 𝗿𝗼𝘂𝗻𝗱 𝗮𝗵𝗲𝗮𝗱.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗤𝟯 𝟮𝟬𝟮𝟲 𝘄𝗮𝘀 𝗮 𝗯𝘂𝘀𝘆 𝗾𝘂𝗮𝗿𝘁𝗲𝗿 𝗳𝗼𝗿 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸, 𝘀𝗼 𝗵𝗲𝗿𝗲 𝗶𝘁 𝗶𝘀 𝗶𝗻 𝗼𝗻𝗲 𝗽𝗼𝘀𝘁.

The @WinkLink_Oracle quarter, date by date:
➜ 𝗝𝘂𝗹𝘆 𝟲: the WIN Buyback and Burn launched, with 100% of service revenue going to quarterly buybacks
➜ 𝗔𝘂𝗴𝘂𝘀𝘁 𝟭𝟳: a TRON DAO release named WIN alongside JST, SUN and BTT in TRON's deflationary era
➜ 𝗦𝗲𝗽𝘁𝗲𝗺𝗯𝗲𝗿 𝟮: TRON's H1 2026 Strategy Report covered WINkLink's upgrades and the buyback
➜ 𝗦𝗲𝗽𝘁𝗲𝗺𝗯𝗲𝗿 𝟭𝟱: WIN/USD and WIN/TRX moved to new 10-decimal feeds
➜ 𝗦𝗲𝗽𝘁𝗲𝗺𝗯𝗲𝗿 𝟯𝟬: USDe/USD and USDe/TRX went live

Two kinds of news ran side by side.

On the token side, the buyback launched and TRON DAO put WIN in the wider deflation story.

On the infrastructure side, the WIN feeds got more precision and a new dollar asset joined the price service.

Both set up what came next.

The buyback set up October's first burn, and the decimals change set up the December 15 deadline for builders.

The full announcements are on the official page:
➜ https://t.co/wExM7X1uSo

𝗢𝗻𝗲 𝗾𝘂𝗮𝗿𝘁𝗲𝗿, 𝘁𝘄𝗼 𝘁𝗿𝗮𝗰𝗸𝘀, 𝗯𝗼𝘁𝗵 𝗺𝗼𝘃𝗶𝗻𝗴.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗙𝗶𝘃𝗲 𝘆𝗲𝗮𝗿𝘀 𝗼𝗳 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸, 𝗶𝗻 𝘀𝗶𝘅 𝗺𝗶𝗹𝗲𝘀𝘁𝗼𝗻𝗲𝘀.

Here's the @WinkLink_Oracle timeline as I'd tell it:
➜ 𝗔𝗽𝗿𝗶𝗹 𝟮𝟬𝟮𝟭: the WINk team acquired https://t.co/QKFS0DTQ58, and WINkLink launched as an oracle on TRON
➜ 𝗠𝗮𝘆 𝟮𝟬𝟮𝟯: Off-Chain Reporting went live on TRON mainnet
➜ 𝗢𝗰𝘁𝗼𝗯𝗲𝗿 𝟮𝟬𝟮𝟰: AnyAPI and Automation entered beta
➜ 𝗝𝗮𝗻𝘂𝗮𝗿𝘆 𝟮𝟬𝟮𝟱: both launched in full
➜ 𝗝𝘂𝗹𝘆 𝟮𝟬𝟮𝟲: the WIN Buyback and Burn launched, funded by 100% of service revenue
➜ 𝗢𝗰𝘁𝗼𝗯𝗲𝗿 𝟮𝟬𝟮𝟲: Round 1 burned 67.36B WIN

What stands out to me is the pacing.

The first few years were about getting price data right on TRON.

The middle stretch added new services on top of that base.

Only then did the token side change, once there was revenue to fund it.

That's the opposite of how a lot of crypto projects run, where the token story comes first and the product follows later, if ever.

The full story starts on the official site:
➜ https://t.co/GsNDubFlvD

𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗳𝗶𝗿𝘀𝘁, 𝘁𝗼𝗸𝗲𝗻𝗼𝗺𝗶𝗰𝘀 𝘀𝗲𝗰𝗼𝗻𝗱.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝟮𝟬𝟮𝟲 𝗴𝗼𝘁 𝘁𝗵𝗲 𝗵𝗲𝗮𝗱𝗹𝗶𝗻𝗲𝘀, 𝗯𝘂𝘁 𝗮 𝗹𝗼𝘁 𝗼𝗳 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸'𝘀 𝗴𝗿𝗼𝘂𝗻𝗱𝘄𝗼𝗿𝗸 𝘄𝗮𝘀 𝗹𝗮𝗶𝗱 𝗶𝗻 𝟮𝟬𝟮𝟱.

Here's that year in five dates from the @WinkLink_Oracle announcements:
➜ 𝗝𝗮𝗻𝘂𝗮𝗿𝘆 𝟳: AnyAPI and Automation launched on TRON mainnet, after a beta that started in October 2024
➜ 𝗝𝗮𝗻𝘂𝗮𝗿𝘆 𝟳: the Platform Roadmap 2025 set out goals all the way to 2027
➜ 𝗝𝘂𝗹𝘆 𝟮𝟭: USD1/TRX joined the price service
➜ 𝗔𝘂𝗴𝘂𝘀𝘁 𝟮𝟮: the Data Services Ecosystem Upgrade opened the doors to data consumers, data providers and node operators
➜ 𝗦𝗲𝗽𝘁𝗲𝗺𝗯𝗲𝗿 𝟮𝟵: the price page added 1-week and 1-month charts, plus contract addresses and transaction hashes

Looking back, 2025 was about widening what WINkLink could do.

Two new services, a new feed, a wider ecosystem and a more transparent price page.

2026 then tied that work to the token, with 100% of service revenue going to WIN buybacks.

The order makes sense to me.

You build the services first, and then you let what they earn shape the token.

Every one of these announcements is still on the official page:
➜ https://t.co/wExM7X22HW

𝗕𝘂𝗶𝗹𝗱 𝗳𝗶𝗿𝘀𝘁, 𝘁𝗵𝗲𝗻 𝗯𝘂𝗿𝗻.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗢𝗿𝗮𝗰𝗹𝗲 𝗳𝗲𝗲𝗱𝘀 𝗱𝗼𝗻'𝘁 𝗹𝗶𝘃𝗲 𝗳𝗼𝗿𝗲𝘃𝗲𝗿, 𝗮𝗻𝗱 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸'𝘀 𝗼𝘄𝗻 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 𝘀𝗵𝗼𝘄𝘀 𝘄𝗵𝘆.

Here are three real changes from the @WinkLink_Oracle announcements:
➜ 𝗕𝗨𝗦𝗗/𝗧𝗥𝗫 𝗮𝗻𝗱 𝗕𝗨𝗦𝗗/𝗨𝗦𝗗 were delisted on 𝗗𝗲𝗰𝗲𝗺𝗯𝗲𝗿 𝟭𝟴, 𝟮𝟬𝟮𝟯, in line with BUSD's own delisting
➜ The 𝗨𝗦𝗗𝗗 pairs moved to 𝗨𝗦𝗗𝗗 𝟮.𝟬 on 𝗝𝗮𝗻𝘂𝗮𝗿𝘆 𝟮𝟳, 𝟮𝟬𝟮𝟱, and the old ones were renamed 𝗨𝗦𝗗𝗗𝗢𝗟𝗗
➜ 𝗟𝗜𝗩𝗘/𝗨𝗦𝗗 was delisted on 𝗙𝗲𝗯𝗿𝘂𝗮𝗿𝘆 𝟱, 𝟮𝟬𝟮𝟲, given the asset's market liquidity and how much the pair was used

That's three different reasons:
➜ The 𝗮𝘀𝘀𝗲𝘁 𝗶𝘁𝘀𝗲𝗹𝗳 was winding down
➜ The 𝘁𝗼𝗸𝗲𝗻 𝘄𝗮𝘀 𝘂𝗽𝗴𝗿𝗮𝗱𝗲𝗱 to a new version
➜ The 𝗺𝗮𝗿𝗸𝗲𝘁 𝗮𝗻𝗱 𝘂𝘀𝗮𝗴𝗲 no longer supported the feed

For LIVE/USD, the notice went out on January 21, about two weeks ahead.

WINkLink advised integrators to adjust their systems and evaluate alternatives in advance.

That's exactly why the docs say not to hard-code feed addresses deep into immutable logic.

Store them where an owner or governance can update them, and a retirement becomes a config change instead of a crisis.

Every one of these notices sits on the announcements page:
➜ https://t.co/wExM7X22HW

𝗕𝘂𝗶𝗹𝗱 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗳𝗲𝗲𝗱 𝘆𝗼𝘂 𝗵𝗮𝘃𝗲, 𝗮𝗻𝗱 𝗽𝗹𝗮𝗻 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗵𝗮𝘁 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝘀 𝗶𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗧𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗪𝗜𝗡 𝗯𝘂𝗿𝗻 𝗿𝗲𝗺𝗼𝘃𝗲𝗱 𝟲.𝟳𝟰% 𝗼𝗳 𝘀𝘂𝗽𝗽𝗹𝘆.

𝗢𝗿 𝟲.𝟳𝟴%, 𝗱𝗲𝗽𝗲𝗻𝗱𝗶𝗻𝗴 𝗼𝗻 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗰𝗼𝗺𝗽𝗮𝗿𝗲 𝗶𝘁 𝘁𝗼.

Both numbers are right, and the gap is a good lesson in reading burn stats.

Round 1 burned 𝟲𝟳,𝟯𝟱𝟳,𝟯𝟲𝟰,𝟱𝟭𝟬 𝗪𝗜𝗡.

Here's the maths both ways:
➜ Against the 𝗶𝗻𝗶𝘁𝗶𝗮𝗹 𝘀𝘂𝗽𝗽𝗹𝘆 of 999B WIN, it's about 𝟲.𝟳𝟰%
➜ Against the 𝘁𝗼𝘁𝗮𝗹 𝘀𝘂𝗽𝗽𝗹𝘆 𝗷𝘂𝘀𝘁 𝗯𝗲𝗳𝗼𝗿𝗲 𝘁𝗵𝗲 𝗯𝘂𝗿𝗻, about 993.70B WIN, it's about 𝟲.𝟳𝟴%

@WinkLink_Oracle quotes the first, which is the more conservative figure.

The second tells you how much of the WIN that existed on the day disappeared.

Put simply, roughly 𝟭 𝗶𝗻 𝗲𝘃𝗲𝗿𝘆 𝟭𝟱 𝗪𝗜𝗡 in existence before Round 1 is gone.

When Round 2 arrives, I'll run the same check both ways:
➜ Round 2's burn divided by the 𝟵𝟵𝟵𝗕 𝗶𝗻𝗶𝘁𝗶𝗮𝗹 𝘀𝘂𝗽𝗽𝗹𝘆
➜ Round 2's burn divided by the 𝟵𝟮𝟲.𝟯𝟰𝗕 𝘀𝘂𝗽𝗽𝗹𝘆 𝗮𝗳𝘁𝗲𝗿 𝗥𝗼𝘂𝗻𝗱 𝟭

The second figure will always come out a little higher, because the base keeps shrinking.

Anyone can check the current supply on the WIN token page:
➜ https://t.co/8HoaREEYD7

𝗦𝗮𝗺𝗲 𝗯𝘂𝗿𝗻, 𝘁𝘄𝗼 𝗵𝗼𝗻𝗲𝘀𝘁 𝗽𝗲𝗿𝗰𝗲𝗻𝘁𝗮𝗴𝗲𝘀.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗛𝗲𝗿𝗲'𝘀 𝗮 𝘄𝗲𝗲𝗸𝗲𝗻𝗱 𝗯𝘂𝗶𝗹𝗱 𝗶𝗱𝗲𝗮: 𝗮 𝘀𝘁𝗮𝗯𝗹𝗲𝗰𝗼𝗶𝗻 𝗽𝗲𝗴 𝗱𝗮𝘀𝗵𝗯𝗼𝗮𝗿𝗱 𝘁𝗵𝗮𝘁 𝗿𝗲𝗮𝗱𝘀 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝘀𝘁𝗿𝗮𝗶𝗴𝗵𝘁 𝗳𝗿𝗼𝗺 𝗧𝗥𝗢𝗡.

No contract, no gas, just off-chain reads.

The @WinkLink_Oracle mainnet table has direct USD pairs for seven dollar assets:
➜ 𝗨𝗦𝗗𝗧/𝗨𝗦𝗗 and 𝗨𝗦𝗗𝗖/𝗨𝗦𝗗
➜ 𝗨𝗦𝗗𝗗/𝗨𝗦𝗗 and 𝗨𝗦𝗗𝗲/𝗨𝗦𝗗
➜ 𝗨𝗦𝗗𝗝/𝗨𝗦𝗗 and 𝗧𝗨𝗦𝗗/𝗨𝗦𝗗
➜ 𝗨/𝗨𝗦𝗗

The dashboard would do three things for each one:
➜ Read the price with 𝗹𝗮𝘁𝗲𝘀𝘁𝗥𝗼𝘂𝗻𝗱𝗗𝗮𝘁𝗮() and scale it with 𝗱𝗲𝗰𝗶𝗺𝗮𝗹𝘀()
➜ Show how far it sits from $𝟭.𝟬𝟬, in basis points
➜ Flag the row if 𝘂𝗽𝗱𝗮𝘁𝗲𝗱𝗔𝘁 is older than you'd expect from that feed's heartbeat

Watch the decimals, because USDe uses 8 while the rest of this list uses 6.

The docs already give TronWeb and tronpy snippets for the read, so the real work is the design.

I'd add a history view with getRoundData for anyone who wants to see how a peg behaved over time.

The proxy addresses are all in the feed table:
➜ https://t.co/MtumISecys

𝗪𝗮𝘁𝗰𝗵 𝘁𝗵𝗲 𝗽𝗲𝗴𝘀 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘁𝗿𝘂𝘀𝘁𝗶𝗻𝗴 𝗮 𝘀𝗰𝗿𝗲𝗲𝗻𝘀𝗵𝗼𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

"𝗛𝗼𝘄 𝘄𝗼𝘂𝗹𝗱 𝘆𝗼𝘂 𝗺𝗮𝗸𝗲 𝗹𝗶𝗾𝘂𝗶𝗱𝗮𝘁𝗶𝗼𝗻𝘀 𝗳𝗶𝗿𝗲 𝗼𝗻 𝘁𝗶𝗺𝗲 𝗶𝗻 𝗮 𝗧𝗥𝗢𝗡 𝗹𝗲𝗻𝗱𝗶𝗻𝗴 𝗮𝗽𝗽?"

𝗜'𝗱 𝗽𝗮𝗶𝗿 𝘁𝘄𝗼 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗻𝗱 𝗮𝗱𝗱 𝗺𝘆 𝗼𝘄𝗻 𝗴𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀.

Here's the design I'd sketch with @WinkLink_Oracle:
➜ 𝗣𝗿𝗶𝗰𝗲 𝗳𝗲𝗲𝗱𝘀 value the collateral, read through the 𝗽𝗿𝗼𝘅𝘆 with latestRoundData
➜ 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 runs checkUpkeep every 3 seconds to look for positions below the threshold
➜ If any exist, 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗨𝗽𝗸𝗲𝗲𝗽 liquidates them, accepting calls only from the upkeep's forwarder

And the guardrails I wouldn't skip:
➜ Reject prices older than your 𝗠𝗔𝗫_𝗣𝗥𝗜𝗖𝗘_𝗔𝗚𝗘 before liquidating anyone
➜ Normalize with 𝗱𝗲𝗰𝗶𝗺𝗮𝗹𝘀() for every feed involved
➜ Keep the upkeep 𝗳𝘂𝗻𝗱𝗲𝗱 𝗶𝗻 𝗪𝗜𝗡, because an unfunded upkeep doesn't run
➜ Be extra conservative with 𝘁𝗵𝗶𝗻𝗹𝘆 𝘁𝗿𝗮𝗱𝗲𝗱 𝗰𝗼𝗹𝗹𝗮𝘁𝗲𝗿𝗮𝗹

The nice part is that checkUpkeep is where the decision happens.

If no position needs liquidating, it returns false and nothing goes further.

Two caveats: this is a sketch, not audited code, and the Automation docs list Nile contracts, so start there.

The Automation flow is here:
➜ https://t.co/CHSeKHRql6

𝗙𝗿𝗲𝘀𝗵 𝗽𝗿𝗶𝗰𝗲𝘀, 𝘁𝗶𝗺𝗲𝗹𝘆 𝗰𝗵𝗲𝗰𝗸𝘀, 𝗰𝗮𝗿𝗲𝗳𝘂𝗹 𝗰𝗼𝗱𝗲.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗥𝗮𝗿𝗲-𝘁𝗿𝗮𝗶𝘁 𝘀𝗻𝗶𝗽𝗶𝗻𝗴 𝗿𝘂𝗶𝗻𝘀 𝗡𝗙𝗧 𝗺𝗶𝗻𝘁𝘀, 𝗮𝗻𝗱 𝗩𝗥𝗙 𝗶𝘀 𝗮 𝗰𝗹𝗲𝗮𝗻 𝘄𝗮𝘆 𝘁𝗼 𝘀𝘁𝗼𝗽 𝗶𝘁.

Here's the build idea.

If traits are fixed in a way people can predict, bots can target the rare ones.

So don't decide them until the randomness is in.

The flow I'd use with @WinkLink_Oracle VRF:
➜ Collectors 𝗺𝗶𝗻𝘁 without knowing their traits
➜ The contract 𝗿𝗲𝗾𝘂𝗲𝘀𝘁𝘀 𝗿𝗮𝗻𝗱𝗼𝗺𝗻𝗲𝘀𝘀 for the batch
➜ In 𝗳𝘂𝗹𝗳𝗶𝗹𝗹𝗥𝗮𝗻𝗱𝗼𝗺𝗪𝗼𝗿𝗱𝘀, each token's traits are assigned from the random numbers
➜ The 𝗽𝗿𝗼𝗼𝗳 is checked on-chain before the contract uses any number

Why this blocks sniping:
➜ The number depends partly on the 𝗻𝗼𝗱𝗲'𝘀 𝗽𝗿𝗶𝘃𝗮𝘁𝗲 𝗸𝗲𝘆, so nobody can compute it ahead of time
➜ The coordinator 𝘃𝗲𝗿𝗶𝗳𝗶𝗲𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝗼𝗳, so nobody can swap in a better number later
➜ Even the 𝘁𝗲𝗮𝗺 can't choose who gets the rare one

Up to 10 random words come back per request, and one large random number can be split across several traits.

At 𝟭𝟬 𝗪𝗜𝗡 per request, batching keeps the cost sensible.

This is a design idea, not a product, so I'd test it on Nile first.

The consumer pattern is in the VRF docs:
➜ https://t.co/5b1iSumNx5

𝗡𝗼𝗯𝗼𝗱𝘆 𝘀𝗻𝗶𝗽𝗲𝘀 𝘄𝗵𝗮𝘁 𝗻𝗼𝗯𝗼𝗱𝘆 𝗰𝗮𝗻 𝗽𝗿𝗲𝗱𝗶𝗰𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗛𝗲𝗿𝗲'𝘀 𝗮 𝗧𝗥𝗢𝗡 𝗯𝘂𝗶𝗹𝗱 𝗶𝗱𝗲𝗮 𝗜'𝗱 𝗹𝗼𝘃𝗲 𝘁𝗼 𝘀𝗲𝗲: 𝗮 𝗳𝗼𝗼𝘁𝗯𝗮𝗹𝗹 𝗽𝗿𝗲𝗱𝗶𝗰𝘁𝗶𝗼𝗻 𝗴𝗮𝗺𝗲 𝘁𝗵𝗮𝘁 𝘀𝗲𝘁𝘁𝗹𝗲𝘀 𝗶𝘁𝘀𝗲𝗹𝗳.

Two @WinkLink_Oracle services could do most of the heavy lifting.

The flow I have in mind:
➜ Players 𝗽𝗶𝗰𝗸 𝗮 𝗿𝗲𝘀𝘂𝗹𝘁 and stake into the contract before kick-off
➜ After the match, the contract makes an 𝗔𝗻𝘆𝗔𝗣𝗜 𝘀𝗶𝗻𝗴𝗹𝗲 𝘄𝗼𝗿𝗱 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 for the final result from a sports data API
➜ Winners are 𝗽𝗮𝗶𝗱 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆 from the pool
➜ If too many players tie for a prize, 𝗩𝗥𝗙 draws the winner fairly

Why these two?

The AnyAPI docs list 𝘀𝗽𝗼𝗿𝘁𝗶𝗻𝗴 𝗺𝗮𝘁𝗰𝗵 𝗿𝗲𝘀𝘂𝗹𝘁𝘀 as an example, and a single word request returns one value, like a score.

VRF covers the tie-break, with up to 𝟭𝟬 𝗿𝗮𝗻𝗱𝗼𝗺 𝗻𝘂𝗺𝗯𝗲𝗿𝘀 in one request and a proof checked on-chain.

A few things the builder would own:
➜ Choosing a 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝘀𝗽𝗼𝗿𝘁𝘀 𝗱𝗮𝘁𝗮 𝘀𝗼𝘂𝗿𝗰𝗲 and writing the 𝗷𝗼𝗯 𝘀𝗽𝗲𝗰
➜ Handling a request that 𝗲𝘅𝗽𝗶𝗿𝗲𝘀 𝗮𝗳𝘁𝗲𝗿 𝟱 𝗺𝗶𝗻𝘂𝘁𝗲𝘀 unanswered, so funds never get stuck
➜ Deciding what happens if a match is 𝗽𝗼𝘀𝘁𝗽𝗼𝗻𝗲𝗱

This is an idea, not a live product, so treat it as a starting brief.

The AnyAPI docs have the single word example to start from:
➜ https://t.co/6bKrYcgV3C

𝗥𝗲𝗮𝗹 𝗿𝗲𝘀𝘂𝗹𝘁𝘀 𝗶𝗻, 𝗳𝗮𝗶𝗿 𝗽𝗮𝘆𝗼𝘂𝘁𝘀 𝗼𝘂𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

"𝗪𝗵𝘆 𝘂𝘀𝗲 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝘄𝗵𝗲𝗻 𝗜 𝗰𝗮𝗻 𝗿𝘂𝗻 𝗮 𝗰𝗿𝗼𝗻 𝗷𝗼𝗯 𝘁𝗵𝗮𝘁 𝗰𝗮𝗹𝗹𝘀 𝗺𝘆 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁?"

𝗬𝗼𝘂 𝗰𝗮𝗻, 𝗯𝘂𝘁 𝗹𝗼𝗼𝗸 𝗮𝘁 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂'𝗱 𝗯𝗲 𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝘂𝗽 𝘁𝗼 𝗯𝗮𝗯𝘆𝘀𝗶𝘁.

A cron bot is a script on a machine you look after.

Here's what @WinkLink_Oracle Automation gives you instead, according to the docs:
➜ 𝗢𝗻-𝗰𝗵𝗮𝗶𝗻 𝗿𝗲𝗴𝗶𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻: the registry tracks which upkeeps exist, their state and their WIN balance
➜ 𝗖𝗵𝗲𝗰𝗸𝘀 𝗲𝘃𝗲𝗿𝘆 𝟯 𝘀𝗲𝗰𝗼𝗻𝗱𝘀 by a node, not a schedule you guessed at
➜ 𝗔 𝗱𝗿𝘆 𝗿𝘂𝗻 𝗳𝗶𝗿𝘀𝘁: simulatePerformUpkeep has to pass before the real call goes out
➜ 𝗔 𝗳𝗼𝗿𝘄𝗮𝗿𝗱𝗲𝗿: your contract can accept performUpkeep only from its own forwarder, not from anyone

With a cron bot, every one of those is your job:
➜ Keep the 𝗺𝗮𝗰𝗵𝗶𝗻𝗲 𝗮𝗻𝗱 𝗶𝘁𝘀 𝗸𝗲𝘆𝘀 online and safe
➜ Decide 𝘄𝗵𝗲𝗻 to call, and pay for the calls that fail
➜ Lock down 𝘄𝗵𝗼 can call your function

That doesn't make a cron bot wrong for a side project.

But for logic that moves user funds, I'd rather the bookkeeping live on-chain than in a script only I can see.

One honest note: the Automation docs list contract addresses for the Nile testnet, so that's where to start.

The full setup is in the Automation docs:
➜ https://t.co/CHSeKHRYaE

𝗙𝗲𝘄𝗲𝗿 𝘁𝗵𝗶𝗻𝗴𝘀 𝘁𝗼 𝗯𝗮𝗯𝘆𝘀𝗶𝘁 𝗺𝗲𝗮𝗻𝘀 𝗳𝗲𝘄𝗲𝗿 𝘁𝗵𝗶𝗻𝗴𝘀 𝘁𝗼 𝗯𝗿𝗲𝗮𝗸.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

"𝗪𝗵𝘆 𝗽𝗮𝘆 𝗳𝗼𝗿 𝗩𝗥𝗙 𝘄𝗵𝗲𝗻 𝗜 𝗰𝗮𝗻 𝗷𝘂𝘀𝘁 𝘂𝘀𝗲 𝘁𝗵𝗲 𝗯𝗹𝗼𝗰𝗸 𝗵𝗮𝘀𝗵 𝗮𝘀 𝗮 𝗿𝗮𝗻𝗱𝗼𝗺 𝗻𝘂𝗺𝗯𝗲𝗿?"

𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝗮 𝗯𝗹𝗼𝗰𝗸 𝗵𝗮𝘀𝗵 𝗶𝘀 𝗽𝘂𝗯𝗹𝗶𝗰, 𝗮𝗻𝗱 𝗩𝗥𝗙 𝗰𝗼𝗺𝗲𝘀 𝘄𝗶𝘁𝗵 𝗮 𝗽𝗿𝗼𝗼𝗳.

The @WinkLink_Oracle VRF docs start with a definition worth knowing.

A VRF is the 𝗽𝘂𝗯𝗹𝗶𝗰-𝗸𝗲𝘆 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗮 𝗸𝗲𝘆𝗲𝗱 𝗵𝗮𝘀𝗵.

Only the holder of the private key can compute it, but anyone with the public key can 𝘃𝗲𝗿𝗶𝗳𝘆 it.

Here's how the two options compare:
➜ 𝗕𝗹𝗼𝗰𝗸 𝗵𝗮𝘀𝗵 𝗮𝗹𝗼𝗻𝗲: one public input, produced by whoever made the block, and visible to everyone at the same moment
➜ 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝗩𝗥𝗙: the block hash is only one of four inputs, alongside your seed, the coordinator's nonce and the node's private key, and the result comes with a proof

That proof is the part that changes everything.

The coordinator checks it 𝗼𝗻-𝗰𝗵𝗮𝗶𝗻 before your contract ever sees the number.

So the node can't swap in a number it likes better, and you don't have to take anyone's word for it.

For a game with real stakes, I'd pay the 𝟭𝟬 𝗪𝗜𝗡 for that every time.

The definition is at the top of the VRF docs:
➜ https://t.co/5b1iSumNx5

𝗣𝘂𝗯𝗹𝗶𝗰 𝗶𝘀𝗻'𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗮𝘀 𝗿𝗮𝗻𝗱𝗼𝗺, 𝗮𝗻𝗱 𝗽𝗿𝗼𝘃𝗲𝗻 𝗯𝗲𝗮𝘁𝘀 𝗯𝗼𝘁𝗵.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗣𝗿𝗶𝗰𝗲 𝗳𝗲𝗲𝗱𝘀 𝗮𝗻𝗱 𝗔𝗻𝘆𝗔𝗣𝗜 𝗰𝗮𝗻 𝗯𝗼𝘁𝗵 𝗽𝘂𝘁 𝗮 𝗻𝘂𝗺𝗯𝗲𝗿 𝗼𝗻-𝗰𝗵𝗮𝗶𝗻.

𝗣𝗶𝗰𝗸𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝗼𝗻𝗲 𝗺𝗮𝗸𝗲𝘀 𝘆𝗼𝘂𝗿 𝗹𝗶𝗳𝗲 𝗵𝗮𝗿𝗱𝗲𝗿.

Here's how I'd choose between the two @WinkLink_Oracle services.

Use a price feed when:
➜ WINkLink 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗹𝗶𝘀𝘁𝘀 𝘆𝗼𝘂𝗿 𝗽𝗮𝗶𝗿 in the feed table
➜ You want a price backed by 𝟳 𝗶𝗻𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝘁 𝗻𝗼𝗱𝗲𝘀 and a median
➜ You'd rather 𝗿𝗲𝗮𝗱 a value than manage requests

Use AnyAPI when:
➜ The data 𝗶𝘀𝗻'𝘁 𝗮 𝘁𝗼𝗸𝗲𝗻 𝗽𝗿𝗶𝗰𝗲, like match results, flight times or traffic
➜ You need a 𝗰𝘂𝘀𝘁𝗼𝗺 𝘁𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 of an API response
➜ You're happy to write your 𝗼𝘄𝗻 𝗰𝗼𝗻𝘀𝘂𝗺𝗲𝗿 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁 𝗮𝗻𝗱 𝗷𝗼𝗯 𝘀𝗽𝗲𝗰, and pay per request in WIN

The trade-off is convenience versus control.

A feed is ready-made, already updating and already spread across 7 nodes.

An AnyAPI job does exactly what you design, but the design, the data source and the funding are all on you.

So I wouldn't use AnyAPI to fetch a BTC price that a 7-node feed already publishes.

And I wouldn't wait for a price feed to cover last night's football score.

The AnyAPI docs show what a custom request looks like:
➜ https://t.co/6bKrYcgne4

𝗥𝗲𝗮𝗱𝘆-𝗺𝗮𝗱𝗲 𝗳𝗼𝗿 𝗽𝗿𝗶𝗰𝗲𝘀, 𝗺𝗮𝗱𝗲-𝘁𝗼-𝗼𝗿𝗱𝗲𝗿 𝗳𝗼𝗿 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗲𝗹𝘀𝗲.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗧𝗵𝗲 𝘃𝗲𝗿𝘆 𝗳𝗶𝗿𝘀𝘁 𝗹𝗶𝗻𝗲 𝗼𝗳 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸'𝘀 𝗽𝗿𝗶𝗰𝗲 𝗳𝗲𝗲𝗱 𝗱𝗼𝗰𝘀 𝗶𝘀𝗻'𝘁 𝗰𝗼𝗱𝗲.

𝗜𝘁'𝘀 "𝗕𝗲𝗳𝗼𝗿𝗲 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗻𝗴, 𝘀𝗲𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗡𝗼𝘁𝗲𝘀."

That one line tells new devs where the real lessons are.

The @WinkLink_Oracle Developer Notes open with a point every new dev should sit with: how a feed performs in your dApp depends on 𝘁𝘄𝗼 𝘁𝗵𝗶𝗻𝗴𝘀.

Here they are:
➜ 𝗠𝗮𝗿𝗸𝗲𝘁 𝗶𝗻𝘁𝗲𝗴𝗿𝗶𝘁𝘆: the real-world market behind the asset, which you don't control
➜ 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗰𝗼𝗱𝗲: the integration you write, which you fully control

The oracle network reports the market.

Your code decides what to do with that report.

So when something goes wrong, the question isn't only "was the oracle right?"

It's also "did my contract handle what the oracle told it?"

That's the mindset shift I'd want a new dev to make before writing their first consumer contract.

The notes then break each half into practical checks, and they're short enough to read over a coffee.

You'll find the Developer Notes at the bottom of the price feed page:
➜ https://t.co/ul3VQxjioW

𝗛𝗮𝗹𝗳 𝗼𝗳 𝗼𝗿𝗮𝗰𝗹𝗲 𝘀𝗮𝗳𝗲𝘁𝘆 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗮𝗿𝗸𝗲𝘁, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗼𝘁𝗵𝗲𝗿 𝗵𝗮𝗹𝗳 𝗶𝘀 𝘆𝗼𝘂.

@justinsuntron @WinkLink_Oracle #TronEcoStar

[SlimMaxOnChain @SlimMaxOnChain]

𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝘆𝗼𝘂𝗿 𝗳𝗶𝗿𝘀𝘁 𝗪𝗜𝗡𝗸𝗟𝗶𝗻𝗸 𝗩𝗥𝗙 𝗰𝗼𝗻𝘀𝘂𝗺𝗲𝗿?

𝗧𝗵𝗲 𝗱𝗼𝗰𝘀 𝗯𝗼𝗶𝗹 𝗶𝘁 𝗱𝗼𝘄𝗻 𝘁𝗼 𝘁𝗵𝗿𝗲𝗲 𝘀𝘁𝗲𝗽𝘀, 𝗽𝗹𝘂𝘀 𝗼𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 𝗽𝗲𝗼𝗽𝗹𝗲 𝗳𝗼𝗿𝗴𝗲𝘁.

Here's the @WinkLink_Oracle direct funding setup:
➜ 𝗜𝗻𝗵𝗲𝗿𝗶𝘁 VRFV2WrapperConsumerBase in your contract
➜ 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 fulfillRandomWords, the callback where your logic handles the random numbers
➜ 𝗖𝗮𝗹𝗹 requestRandomness to start a request

And here's the one people forget:
➜ A direct funding consumer pays for each request 𝗳𝗿𝗼𝗺 𝗶𝘁𝘀 𝗼𝘄𝗻 𝗪𝗜𝗡 𝗯𝗮𝗹𝗮𝗻𝗰𝗲, so it has to 𝗵𝗼𝗹𝗱 𝗲𝗻𝗼𝘂𝗴𝗵 𝗪𝗜𝗡 𝗯𝗲𝗳𝗼𝗿𝗲 𝗶𝘁 𝗮𝘀𝗸𝘀

The docs' sample constructor also shows what your contract needs to know up front:
➜ The 𝗪𝗜𝗡 𝘁𝗼𝗸𝗲𝗻 address
➜ The 𝗪𝗶𝗻𝗸𝗠𝗶𝗱 address
➜ The 𝗩𝗥𝗙𝗩𝟮𝗪𝗿𝗮𝗽𝗽𝗲𝗿 address
➜ How many 𝗿𝗮𝗻𝗱𝗼𝗺 𝘄𝗼𝗿𝗱𝘀 you want per request

On mainnet, the docs list the wrapper as TGDVwQRKwtNHrwy4RFG49b2HTHkvWckP5N and WinkMid as TVMhaFMynYqTRLB1xShYL7wBwdmQHH6bKV.

My tip: check in your request function that the contract's WIN balance covers the fee, so a request never starts unfunded.

The consumer setup is in the VRF docs:
➜ https://t.co/5b1iSumfHx

𝗜𝗻𝗵𝗲𝗿𝗶𝘁, 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁, 𝗿𝗲𝗾𝘂𝗲𝘀𝘁, 𝗮𝗻𝗱 𝗳𝘂𝗻𝗱 𝗶𝘁 𝗳𝗶𝗿𝘀𝘁.

@justinsuntron @WinkLink_Oracle #TronEcoStar