SatchelNEAR Chain Signatures · NFT
An NFT that is a wallet on every EVM chain.
Transfer the NFT and the keys move with it. Buy one and check, on chain, what the seller could have kept back: a signed withdrawal, a leftover approval, anything the record can't explain.
Satchel #1 · one address on 16 chains
0x96DA1468E95Ab31A698891f0150095f86b5a282B
- Ethereum
- Base
- Arbitrum One
- OP Mainnet
- Polygon
- BNB Chain
- Avalanche
- Aurora
Plus each one's testnet. Signed by v1.signer-prod.testnet.
- Contract keys
- …
- Code
- …
- Signer
- …
- Satchels minted
- …
- Listed now
- …
Selling a wallet is easy to fake
The seller signs a withdrawal, sells the wallet, then broadcasts the withdrawal and empties it. Or approves their own address to spend its tokens and pulls them after the sale. Token-bound accounts on one chain have the same holes. Satchel closes them with a record the contract keeps for every token, so a buyer can rule them out instead of trusting the seller.
1
Mint
A satchel is a NEP-171 NFT. Its path, satchel/<id>, and the contract's account derive a secp256k1 key inside NEAR's MPC network. That key is one address on every chain below.
2
Use
The owner asks the contract to sign. The contract builds and hashes the EIP-1559 transaction itself, writes the nonce and any approval into a public record, then requests the MPC signature.
3
Sell
Listing freezes signing. A buyer checks the record, then buys naming the record version they checked; the NFT, and control of the address on every chain, move in one NEAR transaction.
Four checks before you buy
Run in your browser, or with npm run verify -- <id>, against NEAR and each chain the record lists. A satchel is provably clean only when all four pass.
- 1
The contract can't sign behind the record
The contract account has no access keys, runs the reproducible build, and signs only through NEAR's canonical Chain Signatures contract. Nobody, its deployer included, can request a signature for a satchel's key except through sign_evm and sign_raw.
- 2
No signed transaction is still pending
The contract records the highest nonce it ever signed on each chain. Once the address's nonce at a finalized block is above it, every transaction a previous owner signed is either on chain or void.
- 3
No approval left behind
Every approve, increaseAllowance, setApprovalForAll and Permit2 approval the contract signed is itemized. Each one must read as revoked on chain: allowance 0, operator off, approval cleared.
- 4
Nothing the record can't explain
Raw signatures, calls the contract can't classify (multicalls, swaps, ownership transfers) and approvals over the cap are counted. Any one of them makes a satchel unprovable, and the report says so instead of guessing.
Built on NEAR
- Chain Signatures. Every key is derived and every signature made by the MPC network (v1.signer-prod.testnet); the contract is the only account that can ask for a satchel's key.
- NEP-171, 177, 181 and 297. A standard NFT that wallets and marketplaces already understand, with events for every signature and sale.
- A locked, reproducible contract. Built in a pinned Docker image (NEP-330), deployed and initialized in one transaction, then every key deleted.
What it can't cover
- Powers built into an asset itself are out of reach: a token the seller can upgrade, blacklist or claw back needs no signature from the wallet.
- Calls the contract can't classify, such as swaps and multicalls, make a satchel unprovable for every later owner. The report says so.
- secp256k1 only for now: EVM chains through sign_evm, anything else through sign_raw, which counts as opaque.
- Not audited. Two internal adversarial reviews; every fix is covered by the contract's tests.