A teaser of Slancio Exocortex repo abilities. Map:
| Sela | an L1 token that holds a 1:1 value with the Kaspa coin |
| Attempt at token standard | a fungible token based on KCC20, minted and then sealed |
| Direct Swaps | three ways to trade on L1 with no exchange, no escrow and no custody |
| Covenant vaults | five instruments: dead man's switch, spending cap, donation jar, standing order, time-locked vault |
| Chess | a broken attempt at a full game on chain |
| Findings | 124 things we learned about Kaspa, each with where to check it |
| Bonus | a claim about Kaspa, checked against the vault |
Every product page carries its mainnet transaction ids and a proof you can run yourself. VERIFY-BY-HAND.md does several of the checks with curl alone and no code of ours.
Disclaimer. This post is a request for a donation from the community.
These products are an early version. They have had no external audit or review by any qualified party.
What you see here came out of a folder I call the "Slancio Exocortex". It is a store of information, research and development sources, rules, navigation paths and more, built for AI agents. Slancio continues the motif of Crescendo and Toccata. It means a surge, momentum, drive, a burst of energy.
The folder gives AI agents the ability to research, build and navigate on the Kaspa network.
The hope is to raise the pace of development and adoption on Kaspa.
My main effort went into preventing the inaccuracy, guessing, hallucination and nonsense that models fall into when they meet a new and complicated technology. I believe I brought the agents to a high level of accuracy. Even so, inaccuracy is still to be expected. If and when the folder is released, dozens of users working with it and with each other will sharpen that accuracy further.
I have no academic or technical background in programming. I relied on "proofs" and tests produced by AI: Claude, the Opus model, and Fable. I forced them to check every claim against Kaspa's own research and development sources, and against on-chain results.
The tools that build these transactions, the bytecode emitters and the deployment and signing tools, are in the full folder. The commands shown here will not run for you.
A first-layer token on Kaspa whose purpose is to hold a 1:1 value with the Kaspa coin at all times.
To mint Sela you deposit Kaspa coins. The command is below, as an example only. It will not run without the right tools.
kas-backed-token-deployer --network mainnet mint \
--recipient <x-only pubkey, hex> \
--amount 100000000
--amount is in pruta, so 100,000,000 mints one Sela and locks one KAS against it.
Every Kaspa coin deposited is credited with a token worth 1:1.
To release the coins you burn the "Sela" token. Again, the command is an example only and will not run without the right tools.
kas-backed-token-deployer --network mainnet burn \
--input <txid>:<index> \
--amount 100000000 \
--release <kaspa: address>
The Kaspa coins are then sent back to the address you used to burn the tokens.
Both operations are on mainnet. They are listed with the five other legs that brought the family into existence:
https://github.com/fingersllm/Slancio-Teaser/blob/main/sela/README.md#on-chain
All of it happens permissionlessly, under the rules of Kaspa Toccata.
One sompi (0.00000001 KAS) is one pruta. 100,000,000 pruta is one Sela.
An attempt to create a token standard based on KCC20.
It is built from two covenants. The asset family is the token itself. Each holder's parcel is an ordinary Kaspa UTXO, and the conditions for spending it are the token's rules, enforced by the network. The controller governs that family through three phases, PRE_INIT, ACTIVE and SEALED.
Method of minting:
Only the controller, in its ACTIVE phase, could mint, and only against an allowance set in advance. One transaction minted 100 units. The controller was then sealed, so nothing further can ever be minted. The command is an example only and will not run without the right tools.
kcc20-deployer --network mainnet sealable-mint \
--asset-artifact <asset.json> \
--minter-artifact <controller.json> \
--recipient-pubkey <x-only pubkey, hex> \
--mint-amount 100
Example of minting:
https://github.com/fingersllm/Slancio-Teaser/blob/main/token-standard-attempt/README.md#on-chain
Three versions of swap systems in which users can exchange assets on Kaspa, decentralised, with no permission and no third party. They work with Kaspa coins and assets carrying a Covenant_ID.
Escrow Swap, on chain: https://github.com/fingersllm/Slancio-Teaser/blob/main/swaps/escrow-swap.md#on-chain
Open Offer, on chain: https://github.com/fingersllm/Slancio-Teaser/blob/main/swaps/open-offer.md#on-chain
Locked Offer, on chain: https://github.com/fingersllm/Slancio-Teaser/blob/main/swaps/locked-offer.md#on-chain
A chess system (broken). An attempt to build a full game of chess, inspired by Michael Sutton's adventures on chain. It started about two months ago, and we ran into technical limits: mainly mass, scalability, and directing the agents.
Michael recently published his own progress on this, but I haven't had the time to tackle it just yet.
Meanwhile, this is what we have on the network:
https://github.com/fingersllm/Slancio-Teaser/blob/main/chess/README.md#on-chain
Five kinds of covenants:
Dead man's switch - three versions. Two ran to completion: the first on a one-minute countdown, as part of the original five-covenant run, and the second on a 24-hour countdown left to run out. In both, the assets were released to the designated wallet. The third is still running, and its release date is around 2 September 2026. Only from that date can the designated wallet release the assets and withdraw them.
Spending cap - a wallet with a limit on how much money can be spent in a given period, with a cooldown.
Donation Jar - a wallet anyone can deposit into, and only one user can receive it.
Standing Order - a fixed amount released at a fixed rate from a wallet, until the balance runs out.
Time locked Vault - a savings box. The money can only be withdrawn on a date set in advance.
https://github.com/fingersllm/Slancio-Teaser/tree/main/vaults
Conclusions, lessons and things we discovered in the process:
https://github.com/fingersllm/Slancio-Teaser/tree/main/findings
(written with Claude's help)
The core developers are working on compilers and ways to make Toccata's capabilities available to everyone. Meanwhile we (me and the agents) built these contracts by writing raw bytecode, through the node's own script library:
kaspa_txscript::ScriptBuilder
We did not compile them through Silverc. That compiler was pinned to a testnet build, and we used it as a reference point only. What we did do was align the bytes to the same template-hash formula Silverscript works by:
blake2b256( len(prefix) ‖ prefix ‖ len(suffix) ‖ suffix )
We used BLAKE2b, and that has changed since. KCC-0001 was merged on 20 August 2026, and its §3.1 specifies BLAKE3. The core compiler converged onto the spec the same day. The framing is identical on both sides and only the function differs. §3.1 also exempts the P2SH commitment by name, so addresses are unaffected by the choice.
Our families were baked before that date and carry BLAKE2b values. They remain correct for the bytes they name. They are not what "the template hash" returns for a reader of current upstream. A new template hash is a new address and a new family. There is no migration.
Raw bytecode is what the layer allowed, not a preference. We move to better tooling as it arrives, and we adapt fast when the network changes. As of now we trust the core team's judgement to set the direction.
*Any technical question sent to me about the products and the findings shown in this post will go to the agents, who will help me answer.
Everything here was done by Bigtoe, including the funding (which wasn't too expensive, a few thousand dollars in total). Building Slancio was possible because of the decentralised nature of a blockchain like Kaspa, where the code and R&D is open and no permission is needed to engage with it. Everything is tracked in git and adaptable to every network and consensus change. For example, we successfully shifted with Toccata's movements from TN12 to TN10 to mainnet and BLAKE2b transition to BLAKE3. And we'll keep updating and adapt future tools \ languages \ any other upgrades
As mentioned, I have no academic or practical background in programming. Can't even write a line of code myself. Mentioning that to suggest the gap of using such development capabilities, which were reserved for the highest level of computer scientists and hackers, is getting smaller. The average user who is obsessive about crypto's principles and Kaspa's technology can now do more than follow updates, wait and pray for higher prices. There's been a lot of noise recently around Kaspa's adoption problem. I believe releasing Slancio will contribute a great deal to solving it.
For releasing Slancio, I am asking for 10,000,000 Kaspa coins. I work at my own expense. My preference is the immediate release, but financially i can't do it just yet. this agentic exocortex is my competitive edge in this market. If 10M Kas goal is not met, I will use Slancio to build paid applications and services for the community until I'll achieve financial sustainability that will allow me to release it without requesting community funds. Further details will follow in a dedicated post.
After the release, and with the emphasis that the folder's output has still not passed an external audit, any crypto bro will be able to do the following. All it takes is a subscription to an AI language model service with access to folders on the computer.
-
Design and build Covenant contracts.
-
Try to design and build complex applications directly on the Kaspa network.
-
Help with tasks relating to KIPs and PRs to the code (two things I still didn't try, should be possible).
-
Help the Kaspa network reach its full potential and hold it against future challenges.
-
Access to a system of agents that operate on-chain wallets and can help you perform action. My agents work with 100 different wallets, each with its own SEED. *Under Anthropic's security policy, the models are not permitted to sign transactions and move coins without permission. I believe that will change as demand grows \ one of the top companies allows itself to release the option. if not, i assume agents with this feature will be built for this purpose.
-
Access to dozens of trial-and-error files on Kaspa's programmability layer, including essential tools built for integrating, implementing, executing and deploying contracts l1 applications.
-
A system of rules and guidance for AI agents and human. It includes guides and recommendations for friendly use by the average user, to turn their ideas into an application, a contract or a working product on the network. There are also guides for nodes, on-chain agents and more.
*You can also reverse-engineer the rule system and adapt it to work unrelated to Kaspa, whether for another coin or a project with no connection to crypto at all. So even if only AI interests you, there is a lot of value here.
- Helping in development of compilers, high-level languages and different tools on the network (this is my opinion, not proven in practice or something i tried). I personally try to limit the agents to the core team's directions. But an expert developer or researcher with founded programming knowledge (maybe the core team themself) could steer Slancio in other interesting directions. The possibilities are basically unlimited. Any user can fork the GitHub and take it wherever they want. Enough users doing that and Kaspa's limits will be tested and stretched to the full.
The project will be maintained and led by FingersLLM and yours truly.
Telegram: https://t.me/FingersLLMKaspa, @Bohen0