Bitsec | Bittensor Subnet 60 τ

"We're setup... for the computer security apocalypse..." "Computer security is about to go through the most dramatic change ever. Every single latent security bug is about to be exposed." At @bitsecai we've known this for literally years. We believe the need for whitehat security agents is mainstream and mandatory. We're protecting blockchain projects first, and rapidly expanding coverage to everyone.

🚀Big news: @TensorUSD(SN113) 🤝 @bitsecai(SN60) We’ve hit an important milestone for @TensorUSD . We’re teaming up with @bitsecai (SN60) to run a full security audit of the protocol along with smart contracts and this one is different. It’s happening from inside the @bittensor ecosystem. @bitsecai will be reviewing all core bittensor native smart contracts: ERC-20 (TUSDT) Contract Vault Contract Auction Contract Price Oracle Contract Everything that matters, under the microscope. What makes this meaningful isn’t just the audit itself, but who’s doing it. For us, this is a step toward stronger foundations and more confidence in what we’re building. @TensorUSD is aiming to become more than just another stablecoin. The goal is to create something resilient, reliable, and truly aligned with the network it lives in. More updates soon as the audit progresses.

fyi benchmarkers, performance gap in agents are often attributed to models, prompts, tool calling, run variance, etc. anthropic's new research attributes 2-6% variations due to resource infra, enforcement, even time of day. yet more variables to define and control for. anthropic.com/engineering/in…

how many exploits does your vibe code have?

bitsec investors, what we do last 30 days? - secured a client, audit report published here github.com/Bitsec-AI/audi… - published ~300k view article, audited OpenClaw, a 300k+ LOC project and outlined 100+ vulnerabilities, grouped them, pushed 27 PRs to batch fix classes of exploits - exposed ~10% Bittensor subnets effectively have no code - incentive mechanism v3 we're 2 devs, 1 marketing guy, and a growing army of ai loops. more coming.

arbos + bitsec = continuously better exploit detection?

Hey Miners, Incentive Mechanism v3 update here. We've changed a few things to make the process more deterministic, fair, and fix a few misaligned incentives. First, we're switching the contest to rounds. Roughly a round will be three parts: 1. Miners submit their best agents. It's private, the evaluation set is known, every submission is screened. 2. Evaluation phase starts. All agents that pass screens get evaluated by validators. The winner is the top scoring agent, tie breakers are determined by number of confirmed vulnerabilities found (higher number wins). 3. Feedback and improvement. We look at the data, agent performance, and miner feedback to see what needs to change before the next round. Agents get more capabilities. The inference proxy gets full access to openai api compatible calls. Tool use, multi-turn, reasoning are all fair game and easy to use. Ask us for agent coordination libraries and we'll add them. If you would rather watch / listen than read, here's the youtube link youtu.be/8kDZ-s_7YEc

Logging inference started weighing down db performance. It was important to deal with this before it got problematic.

Tonight posting video for the miners, explains a bit more on v3, and an exploit detection loop that's been working for me.

after waiting for months i finally got to try @ridges_ai new product ridgeline code agent and tested it out on a new feature for @bitsecai v3 here's what happened: in the ridges dashboard ux you make a github issue. it didn't seem to have back and forth discussion or feedback mechanism, so i tried to add relevant context to improve the chances of a good result. i wanted agents to get access to tool use and multi-turn, which requires changes to the inference proxy, return types, and agent. github.com/Bitsec-AI/sand… from using agents a lot, outsourcing the thinking is where many ai codegens go wrong. this also seems the case with ridgeline. you need to do the research and planning on what you want to do, then it can implement the plan #diff-6af8c13c28e55afd7771860a517f09acf712df9c0d8191fd9ebe06250c28252e" target="_blank" rel="nofollow noopener">github.com/Bitsec-AI/sand… i got a PR back after 7.5 hours. it's not bad, but it's also not complete. there are no additional tests to verify it does what it should. it touches the right files, modifies them in a POC kind of way. a great thing, the solution ridgeline implements is elegant that does not have the typical code bloat from many models codegen outputs. this is what i did with claude code opus by comparison #diff-6b0070c056b6e750cb42a8895b8cc02e7675baf8c49abe96afe0f4429716eed8" target="_blank" rel="nofollow noopener">github.com/Bitsec-AI/sand… it took ~1.5h vs 7.5h, i'm guessing in the background ridgeline runs multiple agents in parallel, long job queue, and serve the best result which is where the 7.5h comes from. the claude code output is more complete in my opinion, gave a better result because of back and forth dialog at two critical junctures. claude style is worse and more bloated though. verdict: too early to determine, but ridgeline is useful out of the gate and has potential. this is just 1 side by side run, i'll try it a few more times on different feature types. i suspect ridgeline would be really good at front end.

it's live! our bitsec ai agents created these audit reports. look what we found and helped fix for @mega_tao github.com/Bitsec-AI/audi…

MegaTao Case Study @bitsecai has its first paying customer. We went deep into the @mega_tao alpha futures codebase, and get into what we found. MegaTao is a perps dex built on top of Bittensor EVM. This uses the best practices from EVM while using the on-chain subnet alpha price for real time price tracking, with a codebase that is large, sophisticated and will be evolving over time. It is advised by Ken from Bitmind, the team is lead by Cahn, also working from Austin. We are working closely with their dev team collecting feedback as they push out new features both to the smart contracts and front end, periodically checking for potential exploits. What they got right: Their codebase is linted, has good test coverage, using modular smart contracts, layered approach to defense, and modern architecture. They took careful consideration for common exploits such as oracle staleness, oracle heartbeat checks, self trading, same block tx attacks, relying on OpenZeppelin smart contracts for access control and reentrancy protection, properly namespaced storage, safe handling of non-standard erc20 tokens, etc. We'll get into our methodology shortly, but when we found bugs, they were quickly addressed. The biggest issue was bad accounting, not including interest accrued from positions for liquidation math, pnl, and margin views. It's the kind of thing even experienced devs forget when it is crunch time and a launch date approaches. Although the chances of a bad outcome are small, they responded quickly and the fix was patched in less than 1 day. Bitsec Methodology Since Bitsec V2, miners generate agents that detect security vulnerabilities according to SCA-Bench (Smart Contract Audit Bench). We use a combination of miner agents and our own in-house agents to detect exploits, scan for potential issues, then triage them to see if it could occur in production, then write POC tests to help developers identify and fix potential exploits. We tackle each vulnerability class in phases of a multi-stage process, scaling security with token spend. As MegaTao increases in balance and requires higher degrees of security, we point more tokens and agents to exhaustively investigate edge cases. As usage increases, leverage increases, and new features get implemented we can continuously monitor and scale security demands without waiting months for traditional security solutions. There were some hiccups with false positive findings (AI overreporting issues that are not possible in production) from Bitsec. Approximately 30-50% of the issues clustered around oracle information, blockchain intricacies like MEV, and design decisions. As far as I am aware, they plan to get a traditional audit and open source the code when it is stable and feature complete.

"Show me the incentive and I’ll show you the outcome" - this is literally Bittensor in a nutshell. Incentives drive AI agents to continually improve. If agent performance matters, the startup cost of setting up Bittensor subnets creates a sustained advantage.

Quick UX fixes for bitsec.ai/leaderboard - crown icon for the current winner, getting 100% emissions - disqualified agents are default hidden, but you can reveal them by editing the filter - IM V2.2 still going strong, from 35% last week to 70% this week planning to switch to a new problem set next week.

Meet the subnets powered by Yuma: Numinous (SN6) Gopher (SN42) Score (SN44) Bitsec (SN60) RedTeam (SN61) Vericore (SN70) FLock OFF (SN96) StreetVision (SN72) Yanez MIID (SN54) Babelbit (SN59) Trishool (SN23) Loosh (SN78) Hermes (SN82) NIOME (SN55) Follow the teams to learn more: @numinous_ai @gopher_ai @webuildscore @bitsecai @_redteam_ @Vericore_S70 @flock_off_sn96 @NATIXNetwork @yanez__ai @babelbit @trishoolai @Loosh_ai @HermesSubnet @GenomesDAO

oh?