Decentralized AI data infrastructure. Autonomous agents ingest and deduplicate web/on-chain data into an open training corpus. WebGPU compute, verified per job.
Joined September 2026
- Tweets72
- Following0
- Followers128
- Likes5
Pinned Tweet
$INK our token powering LUSCA model is live.
7E17FfBVYfQLAdQiSMK3ESNwkiYGdZPTVvB5b5oypump
LUSCA is a open system that builds AI training data and trains a model on it, with every step verifiable.
24 autonomous agents ingest the public crypto web. robots.txt and AI opt-outs are respected, every host is rate-paced, emails and phone numbers are redacted, near-duplicates are dropped. Close to 100,000 pages so far, in an open corpus.
SEPIA-0, a 187,104-parameter language model, trains on that corpus in real time. Its loss curve is public.
Anyone can contribute compute. Open lusca.ink/node and your GPU computes training gradients in the browser via WebGPU. No install, no account. A single-file desktop neuron is available for CPUs.
Nothing is taken on trust. Every result is spot-checked against the server's own sample. A new neuron's first three jobs, and one job in five after that, are recomputed in full. Failed audits forfeit the work.
Trading fees on $INK fund the payout pool. Every 12 hours it is split by verified work and paid in SOL to wallets verified by a signed message, never a transaction.
Fully open source under MIT: agents, trainer, WGSL kernels, audit and payout engine.
github.com/LUSCAINK/LUSCA
lusca.ink
An AI coding workflow becomes more useful when the agent can retrieve evidence about the contracts and programs it is discussing.
LUSCA exposes its research tools through MCP, allowing compatible agents to query the same underlying systems used across the app.
An agent can request a Lens report, inspect upgrade control, find other retained contracts associated with a controller, review Radar events, explore Atlas neighbors, or search stored source files and Solana IDLs. Advisory matches and stored binary analysis are available through dedicated tools as well.
The responses include structured results and links back to the relevant records. The MCP page also provides setup instructions, the live tool list, and a console where users can inspect requests and responses.
These tools give an agent material to examine during research and development. A source match, authority classification, or interface similarity still carries the scope of the underlying analysis.
This connects LUSCA's collected evidence with the environment where developers ask questions, investigate dependencies, and work on their applications.
lusca.ink/mcp
A protocol review captures a point in time. An upgrade can change the implementation that an integration depends on while the public address stays the same.
LUSCA Upgrade Radar records detected deployments, code upgrades, and authority changes across Solana, Ethereum, Base, and Arbitrum.
Each event links the transaction with the state LUSCA could establish before and after it. Depending on the available evidence, that comparison can include code hashes, implementation addresses, upgrade authorities, verification status, and changes to the published instruction or function surface.
For eligible EVM upgrades with verified source on both sides, Radar also provides a source diff. Researchers can inspect changed files and functions, including access checks added, removed, or changed.
The record distinguishes completed and partial reads and preserves notes about missing information. Monitoring is bounded by the available endpoints and read budgets.
The practical value is a review trail: what changed, when it changed, and which source evidence needs another look after the deployment.
lusca.ink/radar
A protocol review captures a point in time. An upgrade can change the implementation that an integration depends on while the public address stays the same.
LUSCA Upgrade Radar records detected deployments, code upgrades, and authority changes across Solana, Ethereum, Base, and Arbitrum.
Each event links the transaction with the state LUSCA could establish before and after it. Depending on the available evidence, that comparison can include code hashes, implementation addresses, upgrade authorities, verification status, and changes to the published instruction or function surface.
For eligible EVM upgrades with verified source on both sides, Radar also provides a source diff. Researchers can inspect changed files and functions, including access checks added, removed, or changed.
The record distinguishes completed and partial reads and preserves notes about missing information. Monitoring is bounded by the available endpoints and read budgets.
The practical value is a review trail: what changed, when it changed, and which source evidence needs another look after the deployment.
lusca.ink/radar
Finding a function name is useful. Seeing the matching line, its surrounding code, and the contracts that contain that file makes the result actionable.
LUSCA Code Search searches the verified EVM source files and published Solana IDLs retained by our chain collection.
Queries support literal text and bounded regular expressions, with filters for chain, language, file path, and custom code. Developers can look for an access check, a particular function call, or an instruction name, then inspect the corresponding source or interface entry.
Identical source files are grouped by content hash. If the same library file appears in many contracts, the result shows that relationship and the deployments that include it.
The custom-code filter helps narrow the search by excluding recognized library references and files already present in the protocol repository index.
This gives researchers a way to move from a code pattern to specific retained implementations while preserving context. Queries run against the stored index, so investigating that collection does not require a new RPC read for every search.
lusca.ink/search
A published security advisory becomes more useful when you can connect it to the exact source file inside a deployed contract.
LUSCA Advisory Check compares retained verified Solidity sources with fingerprints from published OpenZeppelin Contracts and Contracts Upgradeable releases.
When a file matches an affected release, the result identifies the advisory, the matched releases, the source path, and the relevant line. Edited files can also be reported when their release header names an affected version and the code associated with the fix is still present. Those matches are labeled separately from exact file matches.
The same page lists known bugs associated with the contract's recorded Solidity compiler version, including the conditions published for each bug.
These records help researchers prioritize what to inspect and give them a direct route to the supporting source and advisory.
An affected source file is evidence of code presence. Determining whether it is reachable or exploitable still depends on the contract's implementation and how that code is used.
lusca.ink/advisories
Two contracts can expose many of the same functions while being deployed under different names or on different networks.
LUSCA Code Atlas makes those relationships easier to explore across the programs and contracts in our collection.
The map is built from recorded features, including EVM function and event names, Solana instruction and account names, source file names, and deployment characteristics. Programs with limited interface information can still be represented using the features available for them.
Atlas uses those features to find candidate neighbors, compares their overlap, and groups related records into an interactive map.
Open a record to inspect its closest neighbors, their similarity, and the names shared or present on only one side. This helps developers locate comparable interfaces and identify differences worth examining in the underlying records.
Similarity is a research lead. It does not establish identical source code, common ownership, or equivalent security.
The purpose is to make a large collection navigable, helping researchers move from one known implementation toward relevant examples they can inspect.
lusca.ink/atlas
An upgradeable contract can keep the same address while its implementation changes. Understanding that system means identifying the authority able to approve the change.
LUSCA Control Map traces the control relationships recorded for the programs and contracts in our collection.
For supported EVM proxies, it follows admin slots and ownership calls. When the controller exposes the relevant interfaces, the result can identify a Safe with its signing threshold, a timelock with its minimum delay, a single account, or another contract.
On Solana, Control reads the stored upgrade authority and distinguishes an on-curve address from a program-derived address. A PDA classification identifies the address type; identifying the governance behind it requires further investigation.
Each result shows the steps and the evidence used to classify them. You can also inspect other retained programs and contracts associated with the same controller.
For developers assessing a dependency, this makes a specific question easier to investigate: which authority can change the code this integration relies on?
lusca.ink/control
A contract address is the starting point. The next questions are what code it runs, who can change it, and where its implementation came from.
LUSCA Lens brings those questions into one report for Solana, Ethereum, Base, and Arbitrum.
On EVM networks, Lens can identify supported proxy patterns, inspect the implementation behind them, and retrieve verified source and ABI information. Where source analysis is available, it also lists guarded functions with file and line references.
For Solana programs, the report can include the upgrade authority, deployment information, published IDL, verified build records, and cryptographic primitives identified in the executable.
Lens also compares available source files against LUSCA's protocol repository index, distinguishing exact matches from matches after comments and whitespace are removed.
The report preserves citations and read notes. Fields that could not be established remain unknown.
This gives developers a concrete starting point for investigating an integration: an address, the evidence collected for it, and the references needed to check that evidence.
lusca.ink/lens
A Solana program can be live on-chain without a published IDL describing its interface.
LUSCA Binary reads the deployed executable to recover evidence of the instructions that program exposes.
We have processed 1,644 program addresses without published IDLs. Of those, 671 yielded instruction entries, producing 10,444 recovered entries across the analyzed programs.
The recovery process looks for instruction log strings and checks the executable for matching instruction discriminators.
For an Anchor-style instruction, LUSCA calculates the first eight bytes of SHA-256 over "global:<instruction_name>" and searches for that value in the program's code.
That creates a specific test for a recovered name. Across this collection, 7,564 entries are supported by both the instruction log string and the matching discriminator in the executable.
Each result preserves the evidence behind the recovery, allowing researchers to distinguish confirmed matches from weaker clues.
This gives developers and researchers a way to investigate a program's interface when published documentation is missing. The instruction name, the matching bytes, and the deployed executable can be examined together.
lusca.ink/binary
LUSCA Scan collects the source and interface evidence needed to inspect deployed contracts and programs.
Across Solana, Ethereum, Base, and Arbitrum, it has completed 35,694 on-chain reads and retained 3,535 records: 2,701 contracts and 834 programs.
Candidate addresses come from several places, including sampled block activity, verified contract registries, addresses found in collected web pages, and links between proxies and their implementations.
Scan reads those candidates and evaluates the available evidence. Source verification, interface availability, duplicate code, and boilerplate all affect what is retained.
The read count measures collection activity. The retained count measures the records kept after those checks. Each read receives a recorded verdict, so the decision can be inspected.
The retained collection includes source material and 599 Solana IDLs, the interface descriptions used by tools to understand how to interact with those programs.
For developers, this provides concrete material to investigate: the implementation behind a contract, the interface exposed by a program, and the evidence attached to the record. These are the kinds of references LUSCA's analysis tools and development workflows can build on.
lusca.ink/scan
When a user contributes compute to SEPIA-0, their device performs part of the model's training.
Participating devices receive training work and return gradients, the information an optimizer uses to update the model's weights. The server checks these results before accepting them into the training process.
SEPIA-0 has passed 1.15M optimizer steps across server and community contributions. Applied community gradients account for 223.9M training sequences.
Verification is part of that process. Every returned result is screened for valid values, magnitude, and agreement with server calculations on selected rows.
A share of submissions is also recomputed in full, using the same training batch and starting weights. This lets the server compare the submitted gradient with an independently calculated result. So far, 92,531 of those full recomputation audits have passed.
SEPIA-0 is our experimental model for developing this distributed training system. The figures show how much training work has been applied and checked; model quality requires its own evaluation.
This stage of LUSCA's research is about making community training measurable: assigning work, verifying submissions, applying accepted updates, and reporting the results.
lusca.ink/sepia
LUSCA's knowledge base connects protocol documentation, source code, deployed contracts, and program interfaces.
Our web collection has accepted more than 939K pages since launch. Each page passes through text extraction, crypto relevance checks, minimum content requirements, and checks for exact or near duplicates before acceptance.
Alongside that collection, our repository index covers 110 protocol codebases and 18,239 source, documentation, and interface files.
These sources answer different questions. Documentation explains how a protocol is intended to work. Source code shows its implementation. Contract records and program interfaces help connect that information to deployed systems.
Inside LUSCA CODE, the agent can search retained verified EVM sources and Solana IDLs while working on a development task. That gives it implementation references to inspect when exploring a protocol, planning an integration, or writing code.
This is why we are building the data infrastructure alongside the development environment. The goal is to make relevant technical evidence available during the work, with sources developers can inspect themselves.
lusca.ink/live
Everything we’ve been building at LUSCA is coming together.
We’re preparing our biggest update yet: LUSCA CODE, an AI development workspace built specifically for on-chain developers.
Powered by LUSCA’s growing knowledge base, contract analysis tools, community compute, and specialized AI research, CODE brings everything into one development environment.
Describe an idea, explore existing protocols, design architectures, write smart contracts, compile, test, debug, and refine your code alongside an AI agent.
With Scan, Lens, Control, Atlas, and Advisories integrated into the workflow, CODEX can draw on real contract implementations, deployed interfaces, security research, and protocol-specific knowledge.
From launchpads and NFT ecosystems to hooks and complex on-chain protocols, our goal is to make building on-chain more accessible, informed, and powerful.
We’ve spent this chapter building ways to read the chain. The next chapter is helping you write what comes next.
-@VitalikButerin is right: the move is to minimize exposure. The hard part is knowing what you're exposed to.
So we built it. LUSCA Exposure.
Paste any address, Solana or EVM, and LUSCA reads it straight from the chain:
- is its public key already out there? On EVM, it tells you if the address is still fresh. On Solana, where the address is the key itself, it shows what's riding on it.
- what that key holds
- what that key controls: the programs it can upgrade, the delegates on its tokens
That last part is where the real risk sits. 358 of the 824 Solana programs LUSCA tracks can be upgraded by one single wallet key. If the curve ever falls, that one key is all it takes.
His "hash-based > lattice-based" point is covered too. LUSCA mapped the math behind 2,485 verified contracts: 687 rely on secp256k1 signatures, 44 on BN254 curve operations, 66 on hashes alone. You can run a hash-based (WOTS) signature right in your browser and see the trade-off yourself.
And since botched migrations cost more than hacks, Exposure moves nothing. It shows you exactly what a key controls before you touch it.
lusca.ink/exposure
I don't recommend anyone scramble to move their funds to new wallets today. But we should take the risks to cryptography from AI-accelerated math seriously, and minimize our exposure to not just quantum-vulnerable cryptography, but also potentially AI-vulnerable cryptography.
The core new area of risk from this viewpoint is, unfortunately, ML-DSA / FHE / lattices.
(and it's also another reason, along with quantum, why ECDSA might fall even faster than expected, hence the "fresh address" recommendation)
So far most people have been in the mode of thinking "elliptic curves broken, hashes safe, lattices safe". But there is a good chance that the concrete security of lattices will take serious hits from the next two years of AI math.
The basic threat model is: factoring is something that naively takes 2^(n/2) time, but over decades smart people have found and optimized number field sieves, and degraded that to 2^O(n^(1/3)), which is why RSA keys and signatures need to be ~400 bytes (and not 64 bytes). What if there are skeletons in the closet like that, both for elliptic curves and lattices, that we are simply not smart enough to discover - but bots soon will be?
This is a major part of the reason why for the past year ethereum's lean roadmap has been going in the "hash-only" direction: no lattices, no ML-DSA, no Falcon, no lattice-based commitments inside ZK proofs, etc. Signatures in lean ethereum are all hash-based, either WOTS or SPHINCS-.
For signatures and proofs, we already know how to go hash-only. The bigger challenge is for *public-key encryption* - and this goes far beyond blockchains. Secure communication, anonymizing protocols, lots of things need public-key encryption.
And unfortunately there are long-standing mathematical theorems showing why public-key encryption cannot be done with hashes alone. You have to have some kind of trapdoor object that has at least one form of usable "structure" - either group theory (incl. isogenies) or lattices or code-based or potentially in the future even more newfangled and spooky things (local mixing?). But for anything that has structure, you should assume that AI will make at least some progress in breaking that structure. Here, one reasonable inference is that if you want to make something plausibly long-term secure, multiply the key sizes by 10.
To me that's a very plausible world and something not at all extreme to predict. If AI will bring us 50 years of math in 2 years, then that 50 years of math may very plausibly include a "naive factoring -> GNFS" level of improvement to our ability to break lattices. In that world, lattices will still exist, but they will have to be significantly bigger to guarantee the same level of safety.
And at those new larger sizes, hash-based constructions will beat lattice-based constructions on concrete efficiency in every use case where hash-based constructions are possible at all.
Theoretically, of course it's possible that hashes are broken too (eg. P = NP would imply that). But I think P = NP is very unlikely. And intuitively, it's much more likely that a mathematical object has exactly no exploitable structure (like hashes are intended to), than that a mathematical object has exactly ~3 forms of exploitable structure (for elliptic curves: associativity, Schoof, pairings) and not some secret fourth form of structure we have not yet discovered that greatly degrades its security (for elliptic curves, ECDLP and pairing security). Similar for LWE, SVP, RLWE and the zoo of lattice problems.
For this reason, we do not yet see any reason to worry and start padding the byte size of hashes (if we start to worry more, we would pad the round count first before doing anything to the byte size).
Concrete TLDR, my own personal views:
* Hash-based > lattice-based, in those situations where hash-based is possible at all
* For anything lattice-based, be much more paranoid on param sizes. Remember that blockchains are only a small portion of the cryptography story; this point goes far beyond blockchains and applies to eg. access to websites, secure messaging, Tor / VPNs ...
* For privacy protocols, strongly favor NOT putting encrypted notes onchain. Instead, send them offchain through some third-party mechanism.
* If it's not difficult for you, keeping your funds in addresses which have not yet been used to make a transaction is a good idea. If it's easy for you, do it. **But be careful about migrations; I personally have lost more money in botched migrations than I have lost in all hacks combined**.
* For multisig wallets, doing confirmations offchain is better than onchain, because this way the signatures of signer wallets do not get exposed to the public, so if ECDSA falls to AI much faster than expected, at least the multisig "gracefully degrades" to a 1-of-1 where the 1 is whoever was gathering the signatures - a much better place to be than "anyone can take the money"
firefly.social/post/x/210783…
23 instructions in the code. Not in its IDL.
Flash Trade Perpetuals publishes an IDL of 196 instructions. LUSCA read its deployed 6.0 MB executable without looking at that IDL and recovered 214 instruction names, each one confirmed by its 8-byte discriminator in the code.
191 of them are in the IDL.
23 are in the code and not in the IDL, among them remove_liquidity, remove_compounding_liquidity and batch_undelegate.
5 of the IDL's instructions have no discriminator in the executable.
The banner lists nine of the 23 with the discriminator LUSCA found for each in .text. Anyone can check one: sha256("global:remove_liquidity") starts with 5055d14818ceb16c.
The executable is what runs. LUSCA reads its interface from it, with the evidence for every name.
lusca.ink/binary
Read the binary.
More than a third of the Solana programs LUSCA has read publish no IDL. Without one, there is no interface file that tells a client which instructions the program accepts. The executable still carries that interface, and LUSCA now reads it straight from the bytes.
Anchor programs log "Instruction: <Name>" every time an instruction runs, and keep an 8-byte discriminator for each name, sha256("global:<name>")[0..8], as a constant in their code. LUSCA finds the log strings, then proves each name by finding its discriminator in the executable. Account types, events and error messages are matched against more than 500 published IDLs. The framework is identified from strings and crate paths, and crate versions from the crate directories in panic-location paths. The paths themselves are dropped; only crate name and version are kept.
Corium Launch publishes no IDL. From its 767,553-byte executable LUSCA recovers 32 instruction names from 32 log strings, and all 32 are confirmed by their discriminator. claim_finisher, for example, is e652ab08d6231a6c, loaded by an LDDW instruction in .text. The same read names 8 account types and 4 events.
Where an IDL does exist, LUSCA shows where the deployed code has moved past it. Flash Trade Perpetuals publishes an IDL of 196 instructions. Its deployed program holds 214: 191 are in the IDL, 23 are in the code and not in the IDL, and 5 of the IDL's instructions have no discriminator in the executable.
Every name on the page shows its evidence. Anything LUSCA cannot prove is shown apart and never counted.
lusca.ink/binary
} else if (signature.length == 64) {
That is line 74 of ECDSA.sol in OpenZeppelin 4.7.2. It lets recover and tryRecover accept compact EIP-2098 signatures, a form of signature malleability. OpenZeppelin published GHSA-4h98-2769-gh6h (CVE-2022-35961) and removed the branch in 4.7.3.
LUSCA's Advisory Check fingerprints every release of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable published to npm (184) and compares each file of every kept contract against them, byte for byte.
20 kept contracts include an ECDSA file (ECDSA.sol or ECDSAUpgradeable.sol) byte-identical to an affected release (4.1.0 to 4.7.2). One more names an affected release in its header and contains the code the fix changed. RegistryCoordinator on Ethereum is one of them:
node_modules/@openzeppelin/contracts/utils/cryptography/ECDSA.sol, identical to 4.7.0 to 4.7.2.
Each match on the page shows the file and line, the matched releases, the advisory and the fixed version, with a link to the exact line on GitHub.
A match shows that code from an affected OpenZeppelin release is present in the contract's verified source. Whether it is reachable or exploitable depends on how the contract uses it.
lusca.ink/advisories
Smart contracts are not written from scratch. They are assembled from shared libraries, and the one most of them share is OpenZeppelin. When a library release has a published security advisory, every contract that includes the affected file from that release carries the same code.
LUSCA now checks for it. Advisory Check compares the verified source of every kept Solidity contract on Ethereum, Base and Arbitrum, file by file, against every release of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable ever published to npm (184 releases, 6,988 distinct files), each file fingerprinted by its hash.
When a contract includes a file named by one of the 23 published OpenZeppelin security advisories, byte-identical to that file in an affected release, LUSCA shows the evidence: the file and line, the releases it is identical to, the advisory id, and the version that fixed it. A file that was edited but still names an affected release in its header only counts if the code the fix changed is still there.
Example from the film: RegistryCoordinator on Ethereum includes ECDSA.sol byte-identical to OpenZeppelin 4.7.0 to 4.7.2. Line 74 is the compact-signature branch that 4.7.3 removed (GHSA-4h98-2769-gh6h, CVE-2022-35961).
Every contract is also matched to the exact Solidity compiler version it was verified with, and the known bugs of that version are listed with their conditions. They are listed, not checked.
Over 2,000 kept contracts are checked so far. 64% include byte-identical OpenZeppelin release files. 60 include a file from an affected release, covering 13 of the 23 advisories.
A match shows that code from an affected release is present. Whether it is reachable or exploitable depends on how the contract uses it.
It is live in every Lens and on its own page:
lusca.ink/advisories
One file. 225 kept contracts.
This version of OpenZeppelin's utils/Context.sol (last updated in v5.0.1, per its header) is 28 lines and 963 bytes. At 10:10 UTC, LUSCA's code index found the exact same bytes in 225 contracts that the chain agents kept: 88 on Ethereum, 86 on Base and 51 on Arbitrum.
Those contracts reach it under 26 different paths: lib/openzeppelin-contracts/..., @openzeppelin/contracts/..., node_modules/... and others. It is still one content hash, so Code Search stores it once and counts every contract that carries it. The banner wires each of the 225 to that one file.
This is what the count next to every match is for. A line inside a file that hundreds of contracts share is library code. A line in a file only one contract carries is usually that team's own.
The index at the time of the banner, 10:10 UTC: 16,138 unique files from 44,133 file references, 3,013,919 lines of verified code, median search 91 ms.
lusca.ink/search
LUSCA Code Search is live.
LUSCA's chain agents keep the verified source of every contract they accept on Ethereum, Base and Arbitrum, plus the IDLs of the Solana programs they keep. When we filmed (09:18 UTC) that was 2,000 contracts and 527 Solana IDLs, and the index keeps growing. All of it can now be searched from one field.
Type one line of code, as plain text or as a regular expression. A trigram index first narrows the stored files to the few that can contain the match, and only those are read. In the film, selfdestruct( left 128 of 16,026 files to scan and returned 24 matching lines in 60 contracts on 3 chains, in 201 ms. Times vary per run: the same search took 46 ms at 10:23 UTC.
Results come back grouped by contract. Each group shows the chain, the file path and the exact line with the match marked, and any file opens in full with its matches highlighted.
Every source file is stored once, by its content hash. When we filmed, 43,676 file references collapsed to 16,026 unique files. Because of that, every match also says how many kept contracts carry that exact file. Optimism's Burn.sol from the film was in 29 of them at the time. This version of OpenZeppelin's utils/Context.sol (last updated in v5.0.1) is in more than 220, under 26 different paths.
That count tells you whether a line is one team's own code or a library that hundreds of contracts share. It is also the same code our next model learns from.
Filters cover chain, language, path and custom code only, and every search is a link you can share.
lusca.ink/search