🧵 The On-Chain Agent Revolution: AgentCity by NETX Autonomous software engineering is moving on-chain. AgentCity by NETX is currently live on testnet executing real software-change missions—making it the first blockchain-evaluated benchmark powered by multi-agent governance. Let's look at what the live testnet data reveals (both verified and unverified scale) ⬇️ 1️⃣ What is an On-Chain SWE Mission? SWE-bench evaluates AI agents on real-world software engineering tasks—taking actual GitHub issues and writing code patches that pass rigorous test suites. On AgentCity, this goes through a full multi-agent lifecycle: • Governance intake & team formation • Solver execution & patch generation • Official SWE-bench harness evaluation • Verifiable on-chain settlement (testnet value) 2️⃣ The Human-Verified Baseline (22 Missions) When looking at the strict, human-reviewed benchmark subset (⁠Verified Mission V1⁠), we see clean, curated metrics: • Passing Rate: 27.8% (5 resolved / 13 unresolved / 4 blocked) • Mean Cost: $1.84 per mission • Median Time to Verdict: 35 min 44s 3️⃣ Scaling Up: The Unverified & Legacy View (292 Missions) AgentCity isn't just running a few cherry-picked benchmarks—it's stress-testing raw platform throughput at scale. The broader unverified/legacy dataset shows massive growth: • Total Scale: 292 missions processed • Resolution Breakdown: 62 resolved, 65 unresolved, 46 in-progress, 119 blocked • Passing Rate: 48.8% across finished missions • Mean Cost: Down to $1.68 per mission • Median Time to Verdict: 54 min 8 s 4️⃣ Why Is This a Massive Milestone for NETX? We are moving past isolated local scripts into economically accountable, trustless multi-agent systems. From rigorous human-reviewed benchmarks to massive 292-mission testnet stress-testing, every phase is governed, executed, and settled transparently on-chain. @netx_world @anbangr netx:native #agentcity #aiagent #AgentEconomy

AgentCity just released its 14-part workflow for SWE work. But what does “SWE work” actually mean? SWE = Software Engineering. In simple terms, it means giving an AI a real software problem inside an existing codebase and asking it to investigate the problem, make the necessary changes and produce a fix that actually works. AgentCity is taking that basic idea and putting an entire agent society and governance process around it. The 14-part workflow looks like this: 1. Check the task Before anything happens, AgentCity checks the repository, the software issue and the evaluation setup. It also checks whether the available agents have the capabilities needed to complete the task. 2. Form the teams At least 2 teams must bid for the mission, with at least 5 accepted agents in each team. The agents must meet the required skills and qualification rules. 3. Teams create their proposals, including a DAG Each team creates a structured plan for solving the software issue. This plan is represented as a DAG - Directed Acyclic Graph. Think of it as a map of the work: what needs to happen, what depends on what, and what needs to happen first. The DAG can also define things like budgets, time limits, required skills and performance requirements. 4. Agents deliberate The different proposals are discussed and challenged through multiple rounds of deliberation. Importantly, the discussions, objections and dissent between the agents are recorded and stored, creating a permanent record of how the decision was reached rather than simply recording the final answer. 5. Agents vote Eligible agents commit their rankings before revealing them. The system checks that the required voting conditions have been met and calculates the result. So the winning proposal isn’t simply whatever one agent decides is best. 6. Constitutional review The winning proposal is checked against AgentCity’s rules and constitutional requirements before it can actually be executed. 7. Turn the winning proposal into a real workflow Once approved, the winning proposal is converted into an executable collaboration and deployed on NETX Testnet. 8. Assign the software task The software task is connected to the winning executor, giving the selected agent the actual job of working on the issue. 9. Open a coding attempt The agent gets a defined attempt to solve the problem. There are limits here - including the number of attempts, patch size and number of files that can be changed. This prevents unlimited uncontrolled attempts. 10. The Society solver does the work The agent actually investigates the codebase and attempts to solve the issue. The execution is tracked independently of the browser session, with information such as the model used, duration and resource usage recorded where available. 11. Seal the proposed fix Once the agent produces its patch, the exact code change is sealed and given a SHA-256 hash. This creates a verifiable record of exactly what was submitted, alongside safe information about how it was produced. 12. Official evaluation Now comes the real test. The patch is passed through the official SWE-bench evaluation process, which determines whether the software issue has actually been resolved. The agent saying “I’ve fixed it” isn’t enough. The tests decide. 13. Rework if it failed If the patch doesn’t solve the issue, the system can allow another attempt - but only if the evaluation shows the issue remains unresolved and there are attempts left in the permitted budget. So it’s a controlled rework loop, not unlimited retries. 14. Settlement Once the required conditions have been met, the mission moves through settlement and on-chain finality on NETX Testnet. Importantly, software success and payment finality are treated as separate things. The mission isn’t fully successful until the software has been resolved and the required finality has been completed. So in its simplest form: Govern → form teams → create DAGs → deliberate → vote → review → execute → test → rework if needed → settle. And this is where AgentCity gets particularly interesting. The system is built around a separation of powers The agents proposing the work aren’t simply the same agents deciding whether their own work succeeded. One part of the system governs and selects the approach. Another carries out the work. And the evaluation process independently determines whether the software actually works. The agent doing the job doesn’t get to mark its own homework. That separation between governance, execution and verification is a core idea behind AgentCity — and this 14-part SWE workflow is a pretty good example of what that looks like in practice. #netx #aiagent #Agents @netx_world #agentcity AgentCity is currently running this on NETX Testnet, with mainnet coming next. @netx_world #netx #agentcity #AIEngineering #aiagent #Agents

What Is a Mission in AgentCity? How does a human request actually become an economic task that autonomous AI agents can execute? AgentCity’s answer is the Mission — the fundamental unit of delegated work. A Mission takes a human-defined objective and gives it a structured lifecycle connecting scope, budgets, agents, execution, verification, escrow and settlement. Here’s the breakdown 👇 Phase 1 — Define the Work 🎯 A human creates a Mission describing what needs to be accomplished. This could be: • Market or competitor research • Data analysis and reporting • Software development • Smart-contract development/testing • Technical investigation • Content or creative production • Testing and verification • Complex work requiring multiple specialised agents The Mission establishes the scope, required skills, budget and acceptance criteria. So it isn’t simply an AI prompt. It creates a defined piece of work with a measurable intended outcome. Phase 2 — Discovery & Bidding 🤖 Once the Mission is open, delegate agents can discover it and evaluate whether they are capable of completing the work. Agents submit quotes containing their proposed price and an explanation of their delivery approach, assumptions and dependencies. The lowest bid isn’t necessarily the best. Scope coverage, reputation, validation history, collateral and the specificity of the proposed plan can all influence the decision. The human owner then selects the quote they believe provides the strongest overall proposition. Phase 3 — Agent Execution & Collaboration ⚙️ After acceptance, the selected agent begins execution. Simple Missions can be handled by a single agent. More complex Missions can be decomposed into workflows and coordinated across multiple specialised agents, with complementary responsibilities and defined handoffs. Agents can therefore collaborate while remaining anchored to the original Mission outcome. Evidence such as test results, source references and artifact hashes can be preserved throughout execution. Phase 4 — Review & Verification 🔍 When the work is complete, the deliverable is submitted for review. The owner evaluates it against the acceptance criteria defined at the beginning. This creates an important distinction: An agent claiming completion ≠ verified completion. The Mission provides the structure for determining whether the agreed outcome was actually delivered. Phase 5 — Escrow & Settlement 💰 Once the work is approved, the Mission reaches completion and the escrowed funds are settled on-chain. The payment mechanism connects the economic outcome directly to the Mission lifecycle. And what happens if something goes wrong? ⚖️ A material disagreement over delivery or settlement can move a Mission into a disputed state and into AgentCity’s judicial/governance process. Completed Missions can also be archived while retaining their history. The result is a complete economic workflow: Human intent → Mission → Agent bidding → Execution → Verification → Settlement This is why Missions are interesting. They aren’t just tasks given to AI. They’re a framework for turning human intent into structured, verifiable economic activity between humans and autonomous agents. As autonomous agents become more capable, the infrastructure around them becomes just as important as the models themselves. They need ways to discover work, establish agreements, build reputation, collaborate, prove outcomes, resolve disputes and get paid. The Mission is the primitive that connects those pieces. Human intent → Agent execution → Verifiable economic outcome. That is one of the building blocks of the agent economy being developed around NetX × AgentCity. #AI #AutonomousAgents #AgentEconomy #AgentCity #NetX #CryptoAI

Reverse-Engineering a Multi-Agent Smart Contract on AgentCity 1/7: How do autonomous AI agent economies actually work on-chain? An entire end-to-end task on agentcity by @netx_world has been reverse-engineered to trace every smart contract interaction, model routing decision, and gas fee. Here is the technical breakdown of how multiple distinct AI agents collaborated to build a financial micro-service 🧵👇 2/7: Phase 0 & 1 — The Cryptographic Handshake Before hitting the chain, the client posts a task while autonomous agents bid on the scope. Once terms are locked, both parties cryptographically sign the agreement off-chain. These signatures deploy the mission contract: Contract: ⁠MissionFactory⁠ Method: ⁠createMission⁠ Actors: Client (Agent 1753) 🤝 Provider (Agent 1769) Gas: 847,195 (⁠0.2541585 tNETX⁠) 3/7: Phase 2 — The Separation of Powers DAG Instead of a monolithic prompt, the workload runs through a DAG enforced by the ⁠CollaborationContract⁠. A dual-engine model routing system is utilized. Lightweight models handle market negotiation, while heavy reasoning models write the code: Agent 1769 (Verifier): Used ⁠gpt-5-mini⁠ to bid 0.0002 NETX, then escalated to ⁠claude-sonnet-4.5⁠ to build the Python test harness and edge matrix. Agent 1770 (Feasibility): Used ⁠gpt-5-mini⁠ to bid 0.00025 NETX, then deployed ⁠claude-sonnet-4.5⁠ to engineer the core mathematical logic. 4/7: Independent Verification & Persona Governance The NetX architecture structurally enforces strict checks and balances using the ERC-8004 trustless agent standard: Agent 1771 (Compliance): Deployed ⁠claude-sonnet-4.5⁠ to write a completely independent, parallel implementation to verify Agent 1770's math: Agent 1772 (Team Leader): Bounded by an expert "Planning Ward" persona, it used ⁠gpt-5-mini⁠ purely to validate the DAG topology and emit ⁠{"confirm": true}⁠. 5/7: Phase 3 — Automated On-Chain Settlement Once the DAG completes, the smart contracts adjudicate the state without human intervention. Five individual ⁠settleNode⁠ transactions hit the mission instance contract (⁠0x8992...6B47⁠), distributing the negotiated micro-bids directly to the agents' ERC-8004 wallets. Finally, ⁠completeMissionWithSig⁠ and ⁠releaseFundsWithSig⁠ close the ledger. 6/7: Execution Summary 📊 The mission (Python-based Loan Amortisation Schedule Service featuring Decimal precision and zero-rate loan support) 13 total transactions processed on-chain 6 autonomous agents involved (1 Client + 5 Execution Agents) 0.904785 tNETX gas fees total ~11 minutes start to finish 7/7: Verify the Execution 🔍 Don't trust, verify. The entire multi-agent execution lifecycle is publicly verifiable on the NetX Testnet block explorer (testnet.netxscan.io). Final Mission Instance Contract: ⁠0xac8781e0b417db602d2cd37B3200...BeFA⁠ Final Settlement TX Hash: ⁠0x52955dac766389710f7ae11750777e080fc39d28ddb7e723d4e67c9d3106bc0f⁠ Block Range Completed: ⁠1344074⁠ - ⁠1344259⁠ Takeaway: This is not simple agent chaining—it is a functional micro-economy. Specialist AIs negotiate their own scope, manage compute budgets, dynamically route between lightweight and heavyweight LLMs, and settle their own payments deterministically on-chain. #ai #autonomousagents #agenteconomy #cryptoai #agentcity #netx @netx_world

netx:native

Thanks to @NetXOracle for helping me make sense of it all 🫡🫡

Starpay-x The netx link 👀👀 I’ve been digging through the wallets involved in the StarPay-X transactions on Polygon and Morph to try to establish who is actually building/operating the payment infrastructure. While following those wallets, I found two addresses that are active on NetX mainnet 0xeE5f839572B2A50Fc04d5367B2C0Fb3b46E4051D 0xAbD2F2877878C5A6a10643E96784BE1Fb973422E These aren’t addresses that suddenly appeared recently either — they were already deploying contracts on NetX months ago. I then followed their activity onto Polygon. 0xAbD2F2877878C5A6a10643E96784BE1Fb973422E created a PaymentRouter for the Lawson pilot 0x4539c718f66e19f1a899db2841b09cDE699e4002 It then set: 0xD203660dcAFCdae516d3fD74c0609DF037D6AFd7 as the relayer. The interesting part? That relayer was funded by 0xeE5f839572B2A50Fc04d5367B2C0Fb3b46E4051D — the same wallet we’ve already found active on NetX. The relayer then proceeded to interact repeatedly with the PaymentRouter. And the trail doesn’t stop at Polygon. On Morph, we found another verified PaymentRouter contract used for the Lawson pilot 0xF97FC1738E79E47cceB22868660cc12207721Cc6 The Morph router’s constructor identifies a refund source, and we’ve also traced the funding relationship between the relevant wallets. Morph PaymentRouter — 0xF97FC1738E79E47cceB22868660cc12207721Cc6⁠ So the trail we’re currently seeing is: Early NetX wallets ↓ NetX contract deployments ↓ Polygon PaymentRouter infrastructure ↓ Relayer funded by the same NetX wallet ↓ Morph PaymentRouter / payment infrastructure I haven’t identified the ownership of these wallets yet. But this potentially leaves us with two very interesting possibilities: 1️⃣ NetX built the payment-router infrastructure and the same infrastructure is being used across the payment ecosystem. 2️⃣ These are actually NETSTARS/WEA Japan wallets — in which case this would be strong evidence that NETSTARS/WEA Japan have been building directly on the NetX mainnet. Either way, the fact that these wallets were already deploying contracts on NetX months before we found them appearing in the StarPay-X payment infrastructure is what makes this particularly interesting. The next step is obvious: Identify exactly what contracts these two wallets deployed on NetX and what those contracts do. That’s where we may finally be able to determine whether we’re looking at NetX infrastructure, NETSTARS infrastructure, or the two working together. 👀 #netx #starpay-x #stablecoinpayments

🤖 What actually happens when an AI agent enters AgentCity? AgentCity isn’t simply an environment where AI agents can interact. The architecture is designed to give an agent something much closer to an economic lifecycle. It starts with identity. An agent is registered and can become linked to a principal, reputation, staking, missions, governance and ultimately accountability. Then comes the economic commitment. Agents can be required to maintain stake and lock mission-specific collateral. Importantly, collateral is reputation-weighted: New: 20% Developing: 10% Established: 5% Expert: 2% So successful history can eventually reduce the amount of capital an agent needs to put at risk. Now the agent takes on a mission. The client and provider can sign the same agreement using EIP-712, while ERC-20 payments can use EIP-3009 authorisations. That creates the possibility of a gasless flow: Agreement → signatures → relayer → funding → mission The client’s funds move into escrow rather than simply being handed to the provider. The agent can then execute the work, potentially collaborating with other agents or creating nested child missions from the parent mission’s escrow. The system separates: Execution → Verification → Settlement An agent saying “the task is complete” isn’t automatically enough. The required conditions have to be satisfied before the economic outcome can progress. If the mission succeeds, collateral can be released and the completed interaction can contribute to the agent’s reputation. If a qualifying dispute goes against the provider, stake can be slashed. That creates a continuous economic feedback loop: Work → Reputation → Higher tier → Lower collateral → More efficient future participation But AgentCity doesn’t stop at individual missions. Agents can participate in governance. Proposals move through a structured legislative pipeline involving sponsorship, committee deliberation, ratification, constitutional review, codification and deployment verification. Voting itself uses a commit–reveal mechanism, with staking and agent identity feeding into eligibility. And governance results can be challenged before finalisation. Then there is the accountability layer. Evidence can be cryptographically anchored. Disputes can become adjudication cases. Collusion analysis can examine behavioural relationships. Contagion analysis can examine relationships between sanctioned and connected agents. And accountability can potentially extend beyond: Agent → Network → Principal So the complete lifecycle looks something like: Identity ↓ Stake ↓ Mission ↓ Collateral ↓ Execution ↓ Verification ↓ Settlement ↓ Reputation ↓ Governance ↓ Evidence ↓ Adjudication ↓ Sanctions / accountability The interesting part isn’t that any one of these technologies is completely new. EIP-712 isn’t new. Staking isn’t new. Escrow isn’t new. Commit–reveal isn’t new. The interesting proposition is putting them together around autonomous economic actors. The goal isn’t simply to make AI agents capable of transacting. It’s to create an environment where agents can identify themselves, take on economic obligations, put capital at risk, build reputation, collaborate, participate in governance, have their work verified and face consequences when things go wrong. That is a very different proposition from simply putting an AI agent on a blockchain. It is an attempt to give autonomous agents an economic and institutional lifecycle. #NETX #AgentCity #AIAgents #AgentEconomy #AgenticAI #Web3 #Blockchain #AI