Pinned Tweet
Your walletβs security depends on who can change its rules. Hosted wallets like @privy_io and @turnkeyhq keep those rules inside their own system.
With Lit Protocol, the rules live in contracts on @base. Changing them takes a transaction from your wallet, and anyone can read them.
Teams like @RelayProtocol and @EmblemVault build with Lit for real control.
Ethereum and Solana use different kinds of keys, so a wallet for both usually starts from one seed phrase.
On Lit, one action's key covers both. It works as an Ethereum key as it is, and the same 32 bytes work as a Solana seed.
Here is one action that signs on both chains, with a limit for each and the client code for Solana.
spark.litprotocol.com/walletβ¦
If your AI agent holds a private key, a prompt injection can spend from it.
A safer setup gives the agent a tool that asks for a payment. The key and the rules for each payment stay in an enclave where the agent cannot reach them.
We wrote up how to build that on Lit, with the rule, the tool definition, and the setup calls.
spark.litprotocol.com/give-yβ¦
Auditors will ask you to prove that no employee can reach your customers' keys.
You can answer with a setup where no employee has a technical path to the key, plus checks the auditor can run without trusting you.
Here is how that works on Lit: keys derived in an attested enclave, rules owned by your own Safe on Base, the commands an auditor runs, and the limits to disclose.
spark.litprotocol.com/prove-β¦
You can run a crypto trading bot without a server and without a private key that anyone can copy.
The bot is a Lit Action that Lit Triggers runs every hour. It checks the price, follows limits written into its code, and signs with a key only that code can use.
Here is the whole bot, which sells a little ETH on Base when the price is high, along with the setup commands.
spark.litprotocol.com/cryptoβ¦
Cool build from the community for identity verification!
Scammers don't hack you. They pretendπ.
Someone in your DMs says they're a recruiter, or an admin or mod in a project's Discord? Send them a ProveIt link, powered by @LitProtocol.
Try it (linktr.ee/getproveit):
github.com/heissally/ProveIt
How it works, where the data goes after the model reads it, and what you can verify:
spark.litprotocol.com/ai-on-β¦
You can use an AI vendor's product on sensitive company data while limiting where that data can go.
With Lit, the vendor's container runs in a confidential VM, it can only reach the services you approve, and you check the attestation before sending anything.
The best place for a private key is somewhere your app can ask for a signature without ever reading the key.
On a phone that is the iOS Keychain or the Android Keystore. On a server it is a KMS or a signer your app calls.
This post covers where keys usually leak, what a KMS checks before it signs, and how to put an allowlist and a limit next to the key on Lit.
spark.litprotocol.com/where-β¦
A crypto wallet is a private key and a little code that signs with it. You can write one in a few lines of JavaScript.
The hard part is deciding where the key lives once the wallet holds real money.
We wrote up how to go from ethers on your laptop to a wallet whose key stays in an enclave, with a spending limit written into the code that signs.
spark.litprotocol.com/prograβ¦
If your signer runs in an enclave, you can check what code is actually in there. It takes four steps.
Verify the attestation. Match it to a public build. Confirm TLS ends in the enclave. Look up who approved the code on Base.
Commands for each: spark.litprotocol.com/verifyβ¦
You can add a wallet to your app on Lit with six REST calls and no SDK.
Create a wallet, create a group, write a signing rule, connect them, make a key for your server, and sign. This post walks through each call.
spark.litprotocol.com/walletβ¦
You can use Lit to build any crypto automation you can imagine! Nice example here π
Iβd love to share more about my experimental escrow system I built using @LitProtocol Chipotle (Lit v3), on exactly how it works, because the implementation is the interesting part.
The problem: when two strangers trade an online service (design work, freelance gigs etc), neither wants to go first. Buyers fear paying for nothing. Sellers fear delivering for free.
How I used Lit Protocol to solve it:
1. The referee is a Lit Action. All the decision-making logic (has the seller delivered on time? did the buyer approve? should a dispute go to review?) lives in a Lit Action, a program that runs on Lit's network rather than on a server I control.
2. The escrow wallet's private key only exists inside Lit. It's generated directly from that Lit Action's exact code, using Lit's key derivation. Nobody creates it, stores it, or can extract it, not me, not Lit itself. The code can sign with it; no person ever touches it.
3. The Lit Action reads real on-chain data itself. I paired it with a small logbook smart contract (deployed separately, on Base Sepolia) that only stores and timestamps events: paid, delivered, reviewed, disputed. The Lit Action reads this logbook directly from the chain, through two independent RPC connections that have to agree, rather than trusting any data it's simply handed.
4. The Lit Action pays out itself. Once a decision is final, it signs and sends the payout directly from its own Lit-controlled wallet, with a rule that makes double-payment structurally impossible: the payout can only ever be the wallet's first transaction.
5. I called it through the Lit API directly. I wrote a script that calls Lit's API from my own code, which is what an app or an automated trigger would actually use in production.
I tested this properly before trusting it with anything: 97 automated tests, over 25 deliberate attempts to break the logic (all caught), live runs through the Lit dashboard and the Lit API, and a full real transaction on Base Sepolia - buyer pays, seller delivers, buyer approves, and Lit itself sends the payout from its own wallet. All verifiable on-chain.
This is a proof of concept on a test network, not a production system, no security audit, no real funds(yet). But the mechanism genuinely works end to end;I drove every design decision myself. Stay tuned for my next experiment, which will be built on Lit protocolππ₯
Code, tests, and the full design history are open source; if you want to see how it's put together, you can check it out on GitHub.
More built coming soon,stay tunedπ
Here is how to sign transactions from a backend without keeping a private key on the server.
The key stays in the enclave. The rule that decides each signature runs there too. Your server gets a key that can only ask for signatures.
spark.litprotocol.com/backenβ¦











