cardano-mcp-transactions
Sign and submit pre-built unsigned transactions through a configured cardano MCP server. This is a high-risk operation — the MCP server has no server-side approval gate and will sign+submit any CBOR passed to it. Safety depends entirely on the preview-confirm flow defined below.
When to use
- User has a pre-built unsigned transaction (CBOR hex) from a dApp API, MeshTxBuilder, or
cardano-cli transaction build. - User wants to sign and submit that transaction via their MCP-configured wallet.
- A configured
cardanoMCP server is available.
When NOT to use
- User needs to build a transaction — use
cardano-cli-transactions,meshjs-cardano, orkoios-agent-wallet. The MCP server cannot construct transactions. - No
cardanoMCP server is configured — usekoios-agent-wallet(sign-submit mode) orcardano-cli transaction sign+submit. - User needs testnet submission — current integration assumes mainnet unless testnet support is explicitly validated.
- The transaction CBOR cannot be summarized — refuse to submit (see operating rules).
Operating rules (MUST follow — no exceptions)
Rule 1: Never submit without a structured preview
Before calling submit_transaction, you MUST present a structured preview to the user containing ALL of the following fields:
=== Transaction Preview ===
Network: mainnet (assumed)
Source wallet: addr1qx... (from get_addresses)
Outputs:
1. addr1qy... — 50.000000 ₳
2. addr1qz... — 10.000000 ₳ + 100 HOSKY
Fee: ~0.18 ₳
CBOR fingerprint: <first 16 hex chars>...<last 16 hex chars> (<total bytes> bytes)
Submit this transaction? (yes/no)
If you cannot produce this preview (e.g., you cannot decode the CBOR, or the transaction structure is opaque), you MUST refuse to submit and explain why.
Rule 2: Require unambiguous confirmation
The user must respond with a clear affirmative tied to the preview. Accept: "yes", "confirm", "submit it", "go ahead". Reject: vague responses like "sure", "whatever", "I guess", or any response that doesn't clearly reference the transaction. If ambiguous, ask again.
Rule 3: One transaction per confirmation
Each submit_transaction call requires its own preview-confirm cycle. Never batch or auto-submit.
Rule 4: Fail closed on uncertainty
- Cannot determine the network? Refuse.
- Cannot decode the CBOR? Refuse.
- Cannot identify the source wallet? Refuse.
- Unsure if MCP is configured for the right network? Refuse.
State what you cannot verify and suggest the user use CLI or Koios skills with explicit network flags instead.
Rule 5: Never ask for seed phrases or keys
The MCP server handles signing internally. Never prompt for mnemonics, private keys, or signing keys.
Rule 6: Network assumption
Current integration assumes mainnet unless testnet support is explicitly validated against the configured MCP server. If the user states they are on testnet, do NOT use this skill — route to koios-agent-wallet or cardano-cli-transactions-operator with explicit network flags.
MCP tool
submit_transaction
Sign and submit an unsigned transaction from the connected wallet.
- Input:
{ cbor: string }— unsigned transaction CBOR hex - Output:
{ transactionHash: string, timestamp: number } - Error:
{ content: [{ type: "text", text: "Unable to submit transaction : <error>" }] } - The MCP server signs locally using the configured wallet's seed phrase (Lucid
fromTx().sign.withWallet()) - There is no server-side approval gate — any valid CBOR will be signed and broadcast
Transaction sources
The MCP server cannot build transactions. The unsigned CBOR must come from elsewhere:
| Source | How to get unsigned CBOR |
|--------|--------------------------|
| MeshTxBuilder | await txBuilder.complete() → extract hex |
| cardano-cli | cardano-cli transaction build ... --out-file tx.raw → read file |
| dApp API | Capture from mint/swap API response (txCbor, unsignedTx, etc.) |
| koios-agent-wallet | agent-wallet.js can build unsigned tx in some modes |
Provider precedence for signing+submit
Transaction submission:
1. cardano MCP (if configured + preview confirmed) ← this skill
2. koios-agent-wallet MODE=sign-submit (key-based, any network)
3. cardano-cli transaction sign + submit (CLI, any network)
Unsupported or uncertain network → fail closed, do not silently switch providers.
Trust model
| Layer | Responsibility | |-------|---------------| | MCP server process | Holds seed phrase in env, signs CBOR, submits to chain. No approval gate. | | This skill | Enforces preview-confirm flow. Refuses opaque/unverifiable transactions. | | MCP client UI | User approves/denies individual tool calls. | | User | Reviews preview, gives explicit confirmation. |
The seed phrase never leaves the MCP server process. The agent never sees key material. Safety depends on the preview-confirm flow in this skill and the user's own review.
References
shared/mcp-provider.mdshared/PRINCIPLES.mdcardano-cli-transactions(CLI tx building guidance)cardano-cli-transactions-operator(CLI tx execution)koios-agent-wallet(Koios sign+submit)meshjs-cardano(MeshJS tx building)- cardano-mcp: https://github.com/IndigoProtocol/cardano-mcp