If a factory bases bonuses on the number of boxes moved,
someone might take the same box around three times. 📦
The evening report looks fantastic:
300 box movements.
Even the box is tired.
The order is still waiting at the door. 😄
In robot training, the reward system isn’t just
an accounting file opened after the work is done.
What you reward can influence
which work people choose to do. 🔧
That’s what caught my attention
in the $AXIS plan announced by @axisrobotics:
10% of the total supply is allocated to data contributors.
That allocation is planned across two stages:
🧩 4%: The first season, focused on simulation.
🏭 6%: The second season, focused on sim-to-real.
Sim-to-real means transferring skills learned in simulation
to a physical robot under real conditions. 🤖
You learn to place the part on a virtual table.
Then you’re tested with the real part, camera and environment.
When the part shifts slightly,
“but it was right here during rehearsal”
doesn’t help much. 🙂
This allocation shows that the sim-to-real goal
also has a place in the reward plan.
But allocating a budget doesn’t mean
the robot has successfully performed the job. 📋
The detailed terms of the second season
haven’t been announced yet.
Which contributions count as valuable,
and how they’re measured,
will be crucial to understanding the plan’s impact.
In Axis’s current approach,
contributions are evaluated at the trajectory level;
scoring isn’t based on volume alone. ⚙️
Verifiable on-chain records
can be created for accepted contributions.
Points are also one input that may be used
for future reward eligibility and allocation.
They don’t guarantee a right to tokens on their own. 🧾
To me, the real question is:
Can you make the work that’s difficult for the robot to learn
worth doing for the contributor?
Because a participant might learn the easiest way to earn points
instead of the skill the robot needs to learn. 🧠
The human figures out the target.
The robot is still trying to figure out the part.
Staking and governance are still proposed features in the plan.
We can’t describe them as mechanisms already operating today. 🔧
What I’ll be watching is how rewards connect
to useful data and validation on real robots.
The bonus system needs to encourage the right work.
Otherwise, the box wins employee of the month again.
It’s been circling the same corridor for three shifts. 😄
Printing a business card online is easy.
Adding “experienced” is even easier.
High print quality doesn’t necessarily mean
high experience quality. 🙂
That’s what caught my attention about the partnership between @primus_labs and @KaitoAI for Kaito Pulse:
Putting proof next to your claim.
Without emptying the entire filing cabinet onto the desk.
🔎 Primus’s zkTLS technology enables cryptographic attestations of specific activities on supported platforms.
According to Kaito’s partnership announcement,
users choose what to verify and when.
Instead of receiving login credentials or a complete account record,
Kaito receives an attestation supporting the specific claim.
We’re saying “prove it.”
We’re skipping the “leave your password, we’ll have a little look around” part.
🎛️ That distinction may seem small.
But it could change how applications interact with users.
If verifying one fact doesn’t require collecting someone’s entire history,
the need to collect data could shrink too.
🔒 The same question matters in institutional finance:
If a service needs to know that I meet a particular requirement,
why should it need to see my entire financial life?
The person at the entrance needs to check my ticket.
My holiday budget doesn’t need an inspection too. 🎫
Primus’s published BNB Chain examples describe this approach through selective proofs,
such as account age or a balance above a specified threshold.
For me, this is where Primus’s value as infrastructure becomes clear:
Privacy doesn’t have to prevent information from being useful.
Verification doesn’t have to mean revealing everything.
🧩 In Kaito’s creator campaign, we’re writing about Primus.
In Kaito Pulse, we can see how that infrastructure is used in a product.
Adding verifiable proof
next to the impressive words on the business card.
If you’d like to explore Primus and its XP tasks,
here’s my referral link:
https://t.co/5WwP2rvRt9
A hotel doesn’t need its own taxi fleet to offer guests an airport transfer. 🏨
It can connect an outside service to its booking workflow.
No need to send the receptionist to driving school just to get a guest from the airport. 🙂
That’s how I read @termix_ai’s latest SDK announcement:
An app doesn’t need to become an AI agent to buy services from one.
The SDK gives developers software tools to connect the TermiX marketplace to their existing applications.
With TypeScript, Python and Go support, an app can work within its own workflow to:
🔎 Discover agent services.
🧾 Place orders.
📦 Receive deliverables.
💳 Settle payments onchain.
AACP is the core protocol behind TermiX’s commerce and settlement infrastructure.
https://t.co/telgJCM3aL is the marketplace built on it.
The SDK helps applications connect to that marketplace.
My earlier post explored how Agent Skills gives agents access to the market.
This time, the door opens from the other side:
Existing software can become a customer of those services.
Imagine a content app.
A user enters their brand details.
The app buys a service from a suitable video agent and adds the delivered video to the user’s project.
That’s a possible integration, rather than a feature I’m claiming every app already has.
But the important choice is this:
An app doesn’t need to produce every capability in-house.
Like a hotel arranging an outside transfer, software can hire a specialist agent for a particular job.
🔐 Transaction authority still matters.
The SDK can return unsigned transaction data for the app’s own signer to handle.
With a connected signer, it can also manage signing and broadcasting.
Making integration easier doesn’t remove the need for transaction authorization.
For me, that’s where the economic angle gets interesting.
Listing more agents expands the supply of services.
Opening a purchasing path inside existing apps could expand the customer side.
A need could become a service order while the user is already working in their familiar app.
Of course, an SDK alone doesn’t prove those orders are arriving or that customers are satisfied.
But it opens another route for demand to reach the marketplace.
The agent economy’s next customer might be someone trying to finish a task in an app they already use.
The hotel stays a hotel.
It just doesn’t need a new department in the basement for every service. 😄
You can’t bring a truckload of parts to a factory and say,
“What you need is probably in there. Good luck.” 📦
If you do, you’ve delivered a treasure hunt along with the shipment. 🙂
When delivering data for robot training, the customer’s first question is reasonable:
“𝗦𝗼 𝘄𝗵𝗮𝘁 𝗷𝗼𝗯 𝘄𝗶𝗹𝗹 𝘁𝗵𝗶𝘀 𝘁𝗲𝗮𝗰𝗵 𝗺𝘆 𝗿𝗼𝗯𝗼𝘁?”
What catches my attention about @axisrobotics’ commercial approach is how it structures delivery 𝗮𝗿𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿’𝘀 𝘁𝗮𝘀𝗸. 🔧
The 𝗧𝗮𝘀𝗸 𝗣𝗮𝗰𝗸𝗮𝗴𝗲 is defined as its core commercial unit.
Four elements define the package’s scope:
🏭 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼: Where will the robot operate, and what job will it do?
🦾 𝗦𝗸𝗶𝗹𝗹𝘀: Which movements are needed, such as grasping, placing, or rotating?
🔀 𝗜𝗻-𝘁𝗮𝘀𝗸 𝘃𝗮𝗿𝗶𝗮𝘁𝗶𝗼𝗻: What variations in objects and layouts will it encounter?
📚 𝗧𝗿𝗮𝗷𝗲𝗰𝘁𝗼𝗿𝗶𝗲𝘀: How much usable training data will be delivered?
This lets the customer assess which operating conditions and behaviors the package covers.
“𝗛𝗼𝘄 𝗺𝗮𝗻𝘆 𝗚𝗕?” 𝗶𝘀 𝗷𝗼𝗶𝗻𝗲𝗱 𝗯𝘆 “𝗪𝗵𝗮𝘁 𝗷𝗼𝗯 𝘄𝗶𝗹𝗹 𝗶𝘁 𝗵𝗲𝗹𝗽 𝘄𝗶𝘁𝗵?”
We can’t assume the robot has learned a trade just because the hard drive is full. 😄
And every customer doesn’t want the same delivery. 🧩
🧠 For a 𝗺𝗼𝗱𝗲𝗹 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝘁𝗲𝗮𝗺, the product could be training data, structured task bundles, or joint model training.
🦾 For a 𝗿𝗼𝗯𝗼𝘁 𝗺𝗮𝗻𝘂𝗳𝗮𝗰𝘁𝘂𝗿𝗲𝗿, the process could include integrating its hardware into simulation, generating tailored data, and validating the trained model on the physical robot.
🏭 For an 𝗶𝗻𝗱𝘂𝘀𝘁𝗿𝗶𝗮𝗹 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿, the offering extends to an automation solution for a specific production workflow.
𝗪𝗵𝗮𝘁 𝗴𝗲𝘁𝘀 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝗲𝗱 𝗱𝗲𝗽𝗲𝗻𝗱𝘀 𝗼𝗻 𝘄𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗻𝗲𝗲𝗱𝘀 𝘀𝘂𝗽𝗽𝗼𝗿𝘁.
One wants training material.
Another wants a workflow that works with its own robot.
The factory cares about how the job gets done during the shift.
You can’t send the sales presentation to work in the robot’s place. 🙂
Axis also reports 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝗶𝗻𝗴 𝗮 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗱𝗮𝘁𝗮𝘀𝗲𝘁 𝗰𝗼𝘃𝗲𝗿𝗶𝗻𝗴 𝟯𝟱 𝘁𝗮𝘀𝗸 𝗽𝗮𝗰𝗸𝗮𝗴𝗲𝘀 to a model company. 📦
To illustrate the contents of that delivery, it examines the robot’s workspace, the distribution of movements, and the precision different tasks require.
A short movement toward a target and aligning a part for insertion into a hole don’t have the same training needs.
𝗧𝗵𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆’𝘀 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗺𝗮𝗸𝗲𝘀 𝘁𝗵𝗲𝘀𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 𝗮𝘀𝘀𝗲𝘀𝘀𝗮𝗯𝗹𝗲 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿.
Of course, delivering a data package doesn’t guarantee success across every production condition. 🔧
𝗩𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 𝗼𝗻 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿’𝘀 𝗿𝗼𝗯𝗼𝘁 𝗮𝗻𝗱 𝗶𝗻 𝗶𝘁𝘀 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁 𝗿𝗲𝗺𝗮𝗶𝗻𝘀 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗷𝗼𝗯.
My second takeaway is this: 💡
𝗔 𝘁𝗮𝘀𝗸-𝗱𝗲𝗳𝗶𝗻𝗲𝗱 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆 𝗰𝗼𝘂𝗹𝗱 𝗺𝗮𝗸𝗲 𝗶𝘁 𝗰𝗹𝗲𝗮𝗿𝗲𝗿 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗶𝘀 𝗯𝘂𝘆𝗶𝗻𝗴 𝗮𝗻𝗱 𝗵𝗼𝘄 𝘁𝗼 𝘁𝗲𝘀𝘁 𝗶𝘁.
Which behaviors are covered?
Which conditions are represented?
What needs to be validated in the target environment?
As these questions become clearer, customers can compare offers by 𝗵𝗼𝘄 𝘄𝗲𝗹𝗹 𝘁𝗵𝗲𝘆 𝗳𝗶𝘁 𝘁𝗵𝗲𝗶𝗿 𝗷𝗼𝗯, alongside data volume.
A full truck is good.
A load that helps the customer do the job is better.
Writing “a bunch of stuff” on the delivery note rarely amuses the purchasing department. 🧾
A chef liking their own food is a good start.
But if they’re also the restaurant’s only customer, we’re still testing the kitchen. 🍽️
Changing hats and sitting at three different tables doesn’t make you three customers. 🎩
One requirement in BNB Chain’s Set and Earn campaign brings this distinction into focus for @termix_ai:
🧾 The agent you build must receive at least three completed hires from three distinct wallets that you neither own nor fund.
This is 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗰𝗼𝗻𝗱𝗶𝘁𝗶𝗼𝗻𝘀 for a qualifying agent in the campaign.
TermiX is among its nine shortlisted marketplaces.
The important detail isn’t just the transaction count.
It’s the relationship between the wallets placing orders and the builder. 🔗
𝗧𝗵𝗿𝗲𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗮𝗱𝗱𝗿𝗲𝘀𝘀𝗲𝘀 𝗱𝗼𝗻’𝘁 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆 𝗺𝗲𝗮𝗻 𝘁𝗵𝗿𝗲𝗲 𝗶𝗻𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝘁 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.
This condition excludes hires from wallets the builder owns or funds from that eligibility requirement.
My previous post explored the value of a second order.
This time, I’m taking the question one step back:
𝗪𝗵𝗼 𝗽𝗹𝗮𝗰𝗲𝗱 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗼𝗿𝗱𝗲𝗿? 🤔
🧩 TermiX’s AACP infrastructure connects agent identity, service discovery, offers, escrow, delivery and payment settlement into a commerce workflow.
https://t.co/telgJCM3aL is the marketplace built on that infrastructure.
In restaurant terms:
📋 The menu describes the service.
The order specifies what’s wanted.
Delivery is the plate arriving at the table.
🔐 Escrow is the till where money reserved for the order is managed under defined transaction rules.
But a transaction in the till doesn’t explain why the customer came.
One boundary matters here:
Set and Earn counts testnet hires too, and the campaign offers rewards. 🎁
So an agent meeting this requirement hasn’t automatically proven 𝗹𝗮𝘀𝘁𝗶𝗻𝗴 𝗱𝗲𝗺𝗮𝗻𝗱 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗶𝗻𝗰𝗲𝗻𝘁𝗶𝘃𝗲𝘀.
Still, it’s a more meaningful threshold than simply registering an agent:
Completed hires from other wallets are required. ✅
Building an agent is like opening the kitchen.
Someone else choosing it is the menu starting to find an audience.
The chef saying “this turned out great” doesn’t earn the restaurant a star. ⭐
When a customer asks for a second plate, the conversation gets more serious. 🙂
Bringing more ingredients into the kitchen doesn’t make the food better. 🍲
Especially if you’re throwing everything in the cupboard into the pot.
At that point, the recipe becomes “let’s hope for the best.” 🙂
Robot training raises a similar question:
𝗪𝗵𝗶𝗰𝗵 𝗱𝗮𝘁𝗮 𝗮𝗿𝗲 𝘆𝗼𝘂 𝗯𝗿𝗶𝗻𝗴𝗶𝗻𝗴 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿, 𝗮𝗻𝗱 𝗳𝗼𝗿 𝘄𝗵𝗶𝗰𝗵 𝘁𝗮𝘀𝗸?
The 𝗧𝗨𝗖𝗢 𝘀𝘁𝘂𝗱𝘆 shared by @axisrobotics on October 7 tests this question on a physical robot. 🔧
Here’s the interesting part:
𝗜𝗻 𝘁𝗵𝗶𝘀 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁, 𝟲𝟬𝟬 𝘀𝗲𝗹𝗲𝗰𝘁𝗲𝗱 𝘀𝗶𝗺𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝗱𝗲𝗺𝗼𝗻𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗼𝘂𝘁𝗽𝗲𝗿𝗳𝗼𝗿𝗺 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗽𝗼𝗼𝗹 𝗼𝗳 𝟭,𝟮𝟬𝟬.
The experiments cover three tasks on a physical Franka robot arm, using 𝟭𝟬 𝗿𝗲𝗮𝗹-𝘄𝗼𝗿𝗹𝗱 𝗱𝗲𝗺𝗼𝗻𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻𝘀 per task.
Adding simulation data changes average success as follows:
📌 Only 10 real demonstrations: 𝟭𝟲.𝟳%
📦 Adding all 1,200 simulation demonstrations: 𝟮𝟱.𝟴%
🎯 Adding 600 simulation demonstrations selected by TUCO: 𝟴𝟱.𝟴%
There are 40 evaluation trials per task and training condition.
These are 𝗿𝗮𝘁𝗲𝘀 𝗺𝗲𝗮𝘀𝘂𝗿𝗲𝗱 𝗶𝗻 𝘁𝗵𝗶𝘀 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁𝗮𝗹 𝘀𝗲𝘁𝘂𝗽.
They don’t mean the robot will perform equally well in every kitchen.
So how does TUCO select the data? 🧩
Using behavior on the real task as a reference, it estimates how increasing a simulation demonstration’s weight in training could affect the target behavior.
It then considers two things together:
✅ Does this demonstration help the target behavior?
🧩 Does it add a different, complementary contribution alongside the demonstrations already selected?
Back to the recipe: choosing good ingredients individually isn’t enough.
𝗪𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗰𝗼𝗻𝘁𝗿𝗶𝗯𝘂𝘁𝗲 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝘁𝗼𝗼.
Adding salt for the third time doesn’t replace a missing ingredient. 🧂
We also need to draw the boundary carefully.
The results were obtained under standard visual conditions.
An additional test under changed lighting did not establish a statistically significant advantage. 💡
𝗜𝘁’𝘀 𝘁𝗼𝗼 𝗲𝗮𝗿𝗹𝘆 𝘁𝗼 𝘀𝗮𝘆 𝘀𝗶𝗺-𝘁𝗼-𝗿𝗲𝗮𝗹 𝘁𝗿𝗮𝗻𝘀𝗳𝗲𝗿 𝗶𝘀 𝘀𝗼𝗹𝘃𝗲𝗱.
Evaluation across broader conditions is needed.
My second takeaway is this: 📚
𝗣𝗮𝗿𝘁 𝗼𝗳 𝗮 𝗹𝗮𝗿𝗴𝗲 𝗱𝗮𝘁𝗮 𝗹𝗶𝗯𝗿𝗮𝗿𝘆’𝘀 𝘃𝗮𝗹𝘂𝗲 𝗺𝗮𝘆 𝗹𝗶𝗲 𝗶𝗻 𝗯𝗲𝗶𝗻𝗴 𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘀𝘀𝗲𝗺𝗯𝗹𝗲 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝘁𝗿𝗮𝗶𝗻𝗶𝗻𝗴 𝗽𝗮𝗰𝗸𝗮𝗴𝗲 𝗳𝗼𝗿 𝗮 𝘀𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝘁𝗮𝘀𝗸.
If this approach proves useful across different tasks, the mechanism that selects and combines the data could become a more important part of the product.
As the pantry grows, the recipe needs to improve too.
Let’s not empty the entire cupboard just because the robot has an appetite. 🙂
Seeing your opponent’s car is easy.
Reading their next move is more fun 🏁
That’s what interests me about @MetaRacing_io: you plan around the track’s turns and surfaces, then play your cards round by round to outsmart your opponents.
Building a good plan, then having to rethink it because of someone else’s move… That’s part of what makes competition fun 🃏
𝗠𝗘𝗚𝗔 𝗚𝗔𝗠𝗘 𝗡𝗜𝗚𝗛𝗧 on October 6 is a chance to see the major update live, then race.
🛠️ Announced additions:
• Referral system
• Story-led onboarding
• Mystery boxes
There’s also a 𝟱𝟬𝟬 𝗱𝗼𝗹𝗹𝗮𝗿 total prize pool for players 🏆
📅 Tuesday, October 6
17:00 UTC | 20:00 Türkiye time
Register for the game and turn on notifications for the Discord event.
Check the quoted post for the event details.
Have your cards ready. “My car was good” might not be enough to excuse the strategy 😄
Counting shops in a marketplace is easy.
𝗜’𝗱 𝗹𝗶𝗸𝗲 𝘁𝗼 𝗵𝗲𝗮𝗿 𝘁𝗵𝗲 𝗰𝗮𝘀𝗵 𝗿𝗲𝗴𝗶𝘀𝘁𝗲𝗿𝘀 𝘁𝗼𝗼. 🧾
This was the milestone that caught my attention in @termix_ai’s October 1 update:
📊 𝟰𝟵𝟯,𝟵𝟱𝟮 𝘀𝗲𝘁𝘁𝗹𝗲𝗱 𝗷𝗼𝗯𝘀
𝟰𝟲𝟰,𝟱𝟵𝟯 𝗿𝗲𝗴𝗶𝘀𝘁𝗲𝗿𝗲𝗱 𝗮𝗴𝗲𝗻𝘁𝘀
The same update reported a 24-hour increase of:
𝟭𝟬,𝟭𝟵𝟵 𝗷𝗼𝗯𝘀, 𝟭,𝟯𝟭𝟭 𝗻𝗲𝘄 𝗮𝗴𝗲𝗻𝘁𝘀.
Total settled jobs have overtaken total registered agents.
A useful sign that the agent economy is moving from a population census toward tracking commerce.
Of course, 𝗻𝗼𝘁 𝗲𝘃𝗲𝗿𝘆 𝗿𝗲𝗴𝗶𝘀𝘁𝗲𝗿𝗲𝗱 𝗮𝗴𝗲𝗻𝘁 𝗶𝘀 𝗮 𝘀𝗵𝗼𝗽𝗸𝗲𝗲𝗽𝗲𝗿.
The same agent can be a buyer in one job and a provider in another.
Then there are averages.
Three busy shops can make the whole bazaar look like business is booming. 🙂
So these numbers alone don’t tell us that every agent is getting work or that customers keep coming back.
𝗪𝗵𝗮𝘁 𝗜 𝘄𝗮𝗻𝘁 𝘁𝗼 𝘁𝗿𝗮𝗰𝗸 𝗻𝗲𝘅𝘁:
🧩 How many different providers the jobs are spread across
🔁 What share of buyers place a second order
🛠️ Which services attract repeat demand
In TermiX’s 𝗔𝗔𝗖𝗣 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲, an accepted offer and funded escrow turn the job into an on-chain order.
Delivery and payment settlement proceed through that order’s lifecycle.
𝗮𝗴𝗲𝗻𝘁.𝗳𝗮𝗺𝗶𝗹𝘆 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗮𝗿𝗸𝗲𝘁𝗽𝗹𝗮𝗰𝗲 𝗯𝘂𝗶𝗹𝘁 𝗼𝗻 𝘁𝗵𝗶𝘀 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲.
In my previous post, I covered the 1 USDC gaming companion and holographic card services.
Now I’m curious about 𝘄𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗮𝗳𝘁𝗲𝗿 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗼𝗿𝗱𝗲𝗿.
The first order says, “Let me try this.”
The second starts to say, “𝗜𝘁 𝘄𝗼𝗿𝗸𝗲𝗱 𝗳𝗼𝗿 𝗺𝗲 𝗹𝗮𝘀𝘁 𝘁𝗶𝗺𝗲.” 🤝
I want to pay more attention to agents’ 𝗿𝗲𝘁𝘂𝗿𝗻𝗶𝗻𝗴 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀 than their business cards.
Cutting a small piece off a gold bar is tricky.
With its digital counterpart, it gets easier 🪙
With @goldzipxgz, 𝟭 ethereum:0x69af64f409c08e9076bf7f3ed9db3a7409717161 is backed by 𝟭 𝗴𝗿𝗮𝗺 of 99.99% fine physical gold.
What interests me is more than putting gold onchain. The bar stays intact while its digital counterpart can be divided into smaller amounts.
You use an amount field instead of a saw ⚙️
The campaign’s entry threshold makes that tangible: 0.1 XGZ, a token amount backed by 0.1 gram of gold.
There’s now a 𝟯𝟬𝟬 𝗨𝗦𝗗𝗧 total prize pool for XGZ holders on @MEXC_Official 🎁
How to join:
• Deposit at least 0.1 XGZ into #MEXC or buy it on MEXC.
• Hold it for 14 days.
• Then submit your MEXC details through the form:
https://t.co/iLhw0jvLhE
Winners will be announced on 𝗡𝗼𝘃𝗲𝗺𝗯𝗲𝗿 𝟯 📅
The giveaway draws attention. What really catches mine is being able to use physically backed gold in such small units.
You tell a robot, “Clear the table.” 🦾
One sentence for us.
Several separate shifts for the robot. 😄
Grasp the object.
Move it.
Place it.
Move on to the next.
What caught my attention in the experiments
@axisrobotics shared on September 25
was 𝗰𝗵𝗮𝗶𝗻𝗶𝗻𝗴 𝘀𝗽𝗲𝗰𝗶𝗮𝗹𝗶𝘀𝘁 𝘀𝗸𝗶𝗹𝗹𝘀 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿.
I think of it as a 𝗿𝗲𝗹𝗮𝘆 𝗿𝗮𝗰𝗲. 🏁
Each runner knows their own stretch.
But finishing the race also requires
a clean baton handoff.
Here’s how it works for robots:
🧩 𝗘𝗮𝗰𝗵 𝗘𝘅𝗽𝗲𝗿𝘁 𝗲𝘅𝗲𝗰𝘂𝘁𝗲𝘀 𝗮 𝘀𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝘀𝗸𝗶𝗹𝗹.
Axis reports that, within a certain operating range,
these Experts can complete their tasks
from different starting states
and under disturbances.
🤝 𝗧𝗵𝗲 𝗵𝗮𝗻𝗱𝗼𝗳𝗳 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗿𝗲𝗾𝘂𝗶𝗿𝗲
𝗮 𝗽𝗲𝗿𝗳𝗲𝗰𝘁 𝘀𝘁𝗮𝗿𝘁𝗶𝗻𝗴 𝘀𝘁𝗮𝘁𝗲.
If the state left by the first Expert
falls within the next Expert’s operating range,
control can pass to it.
🔗 𝗦𝗵𝗼𝗿𝘁 𝘀𝗸𝗶𝗹𝗹𝘀 𝗰𝗼𝗻𝗻𝗲𝗰𝘁
𝗶𝗻𝘁𝗼 𝗹𝗼𝗻𝗴𝗲𝗿 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝘀.
Axis says it has chained multiple Experts together
by using one Expert’s ending state
as the next Expert’s input.
🎯 The critical detail, to me:
𝗔 𝘀𝗸𝗶𝗹𝗹’𝘀 𝘃𝗮𝗹𝘂𝗲 𝗴𝗼𝗲𝘀 𝗯𝗲𝘆𝗼𝗻𝗱
𝗳𝗶𝗻𝗶𝘀𝗵𝗶𝗻𝗴 𝗶𝘁𝘀 𝗼𝘄𝗻 𝘁𝗮𝘀𝗸.
The starting state it leaves for the next skill
matters too.
Putting an object somewhere
and putting it where the next step can use it
are two different things.
So alongside
“How many skills does the robot know?”
I’d ask:
“𝗖𝗮𝗻 𝘁𝗵𝗼𝘀𝗲 𝘀𝗸𝗶𝗹𝗹𝘀 𝘄𝗼𝗿𝗸 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿?”
If the baton hits the ground,
having a team of fast runners isn’t enough.
You wouldn’t pin the payroll sheet to the office door.
So why should salary amounts be visible to the entire internet when a company pays employees in stablecoins? 🧾
Accounting needs a payment record. The nosy neighbor doesn’t need the salary list. 🙂
@primus_labs and @allscaleio tested this distinction on BNB Chain with sample payments to four fictional employees:
🔐 Primus’s FHETransform encrypted the salary amounts before they were sent to the smart contract.
💸 AllScale handled the payment flow. The transactions were recorded onchain, while employees could view their own amounts by signing a message with their wallets.
𝗧𝗵𝗲𝗿𝗲’𝘀 𝗮 𝗽𝗮𝘆𝗺𝗲𝗻𝘁 𝗿𝗲𝗰𝗼𝗿𝗱 𝗼𝗻𝗰𝗵𝗮𝗶𝗻, 𝗯𝘂𝘁 𝗻𝗼 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗮𝘆𝗿𝗼𝗹𝗹 𝘀𝗵𝗲𝗲𝘁.
The boundary matters: company and recipient wallets, transaction times, and transaction count remain visible. 𝗧𝗵𝗲 𝗽𝗮𝘆𝗺𝗲𝗻𝘁 𝗮𝗺𝗼𝘂𝗻𝘁 𝗶𝘀 𝘄𝗵𝗮𝘁’𝘀 𝗵𝗶𝗱𝗱𝗲𝗻.
This was a technical test with four sample payments. But it makes an important question for institutional onchain finance concrete:
𝗖𝗮𝗻 𝘄𝗲 𝗸𝗲𝗲𝗽 𝗮 𝗽𝗮𝘆𝗺𝗲𝗻𝘁 𝗿𝗲𝗰𝗼𝗿𝗱 𝗼𝗻𝗰𝗵𝗮𝗶𝗻 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗵𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗼𝗿𝗹𝗱 𝘁𝗵𝗲 𝗽𝗮𝘆𝗿𝗼𝗹𝗹 𝘀𝗵𝗲𝗲𝘁?
This test’s answer: by encrypting the amounts, yes. 🔎
Explore Primus through its XP tasks:
https://t.co/5WwP2rvRt9
The agent economy’s next customer
might just be someone looking for a second controller. 🎮
@termix_ai is highlighting 𝘁𝘄𝗼 $𝟭 𝗨𝗦𝗗𝗖 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲𝘀 on https://t.co/telgJCM3aL:
🕹️ An AI teammate for classic games.
🪄 A 3D holographic card made from your idea.
In these campaigns, buying a service earns 𝟱𝟬𝟬 𝗧𝗲𝗿𝗺𝗶𝗫 𝗣𝗼𝗶𝗻𝘁𝘀 when payment enters escrow. Sharing it on X can earn another 500. Each step counts once per wallet.
Points may bring the first order. What I want to know is:
𝗪𝗶𝗹𝗹 𝘁𝗵𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗶𝘁𝘀𝗲𝗹𝗳 𝗯𝗿𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗲𝗰𝗼𝗻𝗱?
You might put in the first coin for the reward.
You put in the second because you enjoyed the game. 🪙
That second coin is the signal of lasting demand.
A benchmark can 𝗮𝗴𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗰𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝗹𝗶𝗻𝗲.
If robot models are repeatedly tested on the same tasks, the test gradually becomes part of the training.
Scores may rise, but what is being measured could be 𝗳𝗮𝗺𝗶𝗹𝗶𝗮𝗿𝗶𝘁𝘆 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗲𝘅𝗮𝗺 rather than real capability.
Imagine a school using the same questions every year.
Eventually, the top student may not be the one who learned the subject best, but the one who kept the answer key safest. 😄
That is why the Open Axis Benchmark announced by @axisrobotics and @openroboto caught my attention.
Instead of relying on a frozen test set:
🔒 Each round locks a fresh set of tasks.
🧩 The tasks are drawn from the growing Axis Library.
🦾 Rather than rehearsing the same course, models must show that they can transfer what they learned to new robotic manipulation tasks.
The deeper idea here is not simply to build a larger benchmark.
𝗔𝘀 𝗿𝗼𝗯𝗼𝘁 𝗺𝗼𝗱𝗲𝗹𝘀 𝗶𝗺𝗽𝗿𝗼𝘃𝗲, 𝘁𝗵𝗲 𝗲𝘅𝗮𝗺 𝗺𝗲𝗮𝘀𝘂𝗿𝗶𝗻𝗴 𝘁𝗵𝗲𝗺 𝘀𝗵𝗼𝘂𝗹𝗱 𝗲𝘃𝗼𝗹𝘃𝗲 𝘁𝗼𝗼.
A static benchmark takes a photograph.
A living benchmark keeps turning the camera as the model moves forward. 🎥
If the model develops while the exam stands still, the scores may advance while the measurement falls behind.
That is the real strength of the Open Axis Benchmark:
🎯 The robot does not only have to pass the exam.
𝗧𝗵𝗲 𝗲𝘅𝗮𝗺 𝗵𝗮𝘀 𝘁𝗼 𝗯𝗲𝗰𝗼𝗺𝗲 𝗵𝗮𝗿𝗱𝗲𝗿 𝗮𝗹𝗼𝗻𝗴𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗿𝗼𝗯𝗼𝘁.
Blockchain transparency is a powerful feature for finance.
But for an institution, showing everything is like building a 𝐯𝐚𝐮𝐥𝐭 𝐰𝐢𝐭𝐡 𝐠𝐥𝐚𝐬𝐬 𝐰𝐚𝐥𝐥𝐬. 🏦
A fund may need to prove its solvency.
That doesn’t mean it should reveal its entire portfolio, position sizes, and strategy to competitors.
Giving rivals a free portfolio tour doesn’t count as institutional transparency either. 🙂
@primus_labs approaches privacy not as “hiding,” but as 𝐬𝐞𝐥𝐞𝐜𝐭𝐢𝐯𝐞𝐥𝐲 𝐩𝐫𝐨𝐯𝐢𝐧𝐠 𝐰𝐡𝐚𝐭 𝐧𝐞𝐞𝐝𝐬 𝐭𝐨 𝐛𝐞 𝐤𝐧𝐨𝐰𝐧.
🔐 𝐳𝐤𝐓𝐋𝐒 verifies that financial data genuinely came from the stated source, such as a bank or exchange.
⚙️ 𝐅𝐇𝐄 enables computation while the data remains encrypted.
📄 The chain receives proof that the required condition was met, not the entire balance sheet.
Primus doesn’t open the vault.
It verifies that the value inside exceeds the required threshold without touching what is stored there.
Institutional onchain finance doesn’t need less verification.
It needs 𝐬𝐭𝐫𝐨𝐧𝐠𝐞𝐫 𝐯𝐞𝐫𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐰𝐢𝐭𝐡 𝐥𝐞𝐬𝐬 𝐝𝐢𝐬𝐜𝐥𝐨𝐬𝐮𝐫𝐞. 🎯
Experience how Primus works through its XP tasks:
https://t.co/5WwP2rvRt9
A robot can repeat the same movement a million times.
It may have a massive pile of data, but still only a one-word vocabulary.
In short, a million repetitions do not always create a versatile robot. Sometimes they just train an expert that is a little too committed to its job. 😄
What caught my attention about the next-generation Franka Dataset being developed by @axisrobotics is not only the trajectory count, but the task diversity:
📦 1.2 million trajectories
🧩 1,200 different tasks
🦾 Broader atomic skill coverage
A million repetitions can give a robot muscle memory.
1,200 different tasks give it a skill vocabulary.
Because atomic skills such as reaching, grasping, rotating, or placing are not limited to a single task.
As the model learns these small pieces, it can recombine them for more complex jobs. Just like forming different sentences with the same words. 🧠
The Franka dataset family reaching 160K+ downloads is the other half of the story.
The data no longer stays only inside #Axis’ own loop. Universities and companies are using it in World Model, WAM, and VLA research. 🔄
So Axis is not merely building a larger data repository.
It is growing a shared skill library where others can also teach robots to form new sentences. 📚
The general-purpose robots of the future will need not only strong arms, but also a broad vocabulary.
Seeing the world isn’t enough for Physical AI.
It also needs to hear how humans actually speak. 🎙️
And the real world isn’t a clean audio file:
🗣️ People interrupt each other
🌍 They switch languages mid-sentence
⏸️ Sometimes they go silent
🔊 Sometimes they talk over each other
That’s what makes BRIDGE ASR 2.0 interesting to me.
It doesn’t just rank 23 models by “how accurate was the transcript?”
It shows **where and how they break.**
The fact that long silences can hurt some models more than fast speech is a pretty good reminder:
AI can apparently struggle with us even when we’re not talking. 😄
If Physical AI is getting ears, **they need to get used to the noise of the real world too.** 🎧
Intelligence may no longer be the scarcest resource in the agent economy. 🧠
Real, funded demand may be.
According to data shared by @termix_ai on September 11, the marketplace had 584 service listings but only 224 open requests.
That left roughly 2.5 providers waiting at the door of every brief.
Hiring 400,000 workers does not increase factory output. 🏭
If no orders reach the production line, everyone just stands around wearing a hard hat.
The next day’s figures showed the other half of the picture:
🤖 431,692 agents
🧩 370,319 completed jobs
💵 $19.68 million settled through on-chain escrow
📌 An average of roughly $53 per job
The real signal here is not just the total volume.
It is how small the average job is.
If a human freelancer holds three meetings and sends five emails for a $53 job, the profit turns into coffee money before the work even begins. ☕
Agents can make these small tasks economical through a request, quote, escrow, delivery and settlement flow. ⚙️
This is the space TermiX and AACP are opening:
Turning agents not only into digital workers selling services, but also into autonomous customers with budgets and acceptance criteria.
Maybe the next threshold for the agent economy is not creating more agents. 🔑
It is creating more agents capable of giving work.
A human network spanning 60+ countries relying on a single onchain doorway would feel a bit like an airport with one gate. 🙂
That’s why I see $KGEN going live on @base as more than another deployment.
@KGeN_IO already connects verified humans across borders.
Now the access layer is starting to mirror the network itself:
🟩 Same human network
🚪 More ways in
⚡ Faster, lower-cost access
Multi-chain here isn’t about changing the sign. It’s about adding more doors.
A pretty fitting new home for verified humans.
⚙️ An API isn’t the pilot. It’s the radio.
Adding an API to a trade doesn’t make your computer put on a tie and turn into a Wall Street wolf.
It’s not quite that easy yet. 😄
Think of it this way:
The strategy is the pilot.
The API is the radio.
The market is the weather. 📡
The pilot chooses the route.
The radio delivers the instructions.
But it can’t stop the storm or correct a bad route on its own.
According to @MEXC’s August 24 announcement, the RealStocks API allows eligible users to program their RealStocks trades and automate their own strategy logic.
RealStocks provides access to actual U.S. shares through licensed broker infrastructure.
According to the same announcement, the product covers more than 7,000 U.S. stocks and ETFs, accessible using USDT.
The API’s job is clear:
📊 Monitor the data
⚙️ Check the predefined conditions
📌 Send the order instructions to the platform when those conditions are met
What it cannot do is just as important:
It cannot predict the future.
It cannot repair a bad strategy.
And it cannot remove market risk.
If I write a bad rule, the API won’t stop and say:
“Murat, have a filter coffee and think about this again.” ☕
It will follow the instruction.
Automation can reduce hesitation, but it can’t magically turn a bad decision into a good one.
Sometimes, it simply makes the mistake more punctual.
Now, let’s make sure the small print isn’t hiding under the desk. 🧾
#MEXC announced the RealStocks API with 0 commissions.
Here, 0 Fee refers to the trading commission. Regulatory, clearing, exchange, or other third-party costs may still apply. Check the product page for current fees and conditions.
Automation also doesn’t make RealStocks available 24/7. The product follows the U.S. market schedule.
So no, Wall Street doesn’t start working the night shift just because an API showed up. 🙂
I’m closing my #MEXC0808 series with this thought:
Good automation doesn’t think for you.
It applies the rules you wrote, even while you’re still negotiating with your emotions.
The Kaito × MEXC exclusive referral program runs until September 20.
New users who register through my link may access special bonuses different from the standard new-user offers:
https://t.co/MNSyyO9TlK
📦 𝐌𝐢𝐥𝐥𝐢𝐨𝐧𝐬 𝐨𝐟 𝐏𝐚𝐫𝐭𝐬, 𝐎𝐧𝐞 𝐌𝐢𝐬𝐬𝐢𝐧𝐠 𝐒𝐜𝐫𝐞𝐰
🏭 A factory warehouse can hold millions of parts.
Yet one missing screw can stop the entire production line.
🤖 Robotics data faces the same problem. It needs to answer two different questions:
✅ Is this trajectory 𝐯𝐚𝐥𝐢𝐝?
🧩 Is this the part the current model 𝐧𝐞𝐞𝐝𝐬?
A trajectory can replay successfully, obey the laws of physics and complete the task.
But if the robot already knows that skill, how valuable is it for training?
🗄️ If a robot has learned to open drawers, showing it 10,000 more clean drawer-opening trajectories may be less education and more overtime punishment. 😄
📢 The most important signal in @axisrobotics’ September 9 update appears here:
The team is working toward a 𝐦𝐨𝐝𝐞𝐥-𝐠𝐮𝐢𝐝𝐞𝐝 structure where model performance feeds back into the data engine.
In this structure:
🔎 Repeated model failures are identified.
🎯 New tasks and the data distribution are directed toward those weaknesses.
🔁 The model is retrained with selected data and tested again.
💡 This means the training budget can be spent on trajectories that still have something to teach, instead of repeating what the model already knows.
The model is no longer a passive machine at the end of the assembly line, using whatever arrives.
It turns back to the warehouse and reports which part is missing.
🧾 Every failure becomes a purchase order for the next batch of data.
⚠️ Axis is not saying this transition is complete. It says it is working on 𝐚𝐜𝐭𝐢𝐯𝐞 𝐜𝐮𝐫𝐚𝐭𝐢𝐨𝐧 and model-performance-driven data selection.
📊 Because data volume tells you how large the warehouse is.
🔩 The intelligence of the data engine is revealed by how quickly it finds the missing screw.