ContinuumDAO Forum

Private Ethereum is live in Multi-Party Agent Wallet with @RAILGUN_Project so that now you can move private balances for ETH, USDC, USDT and more, all using our built-in AI agent and human-in-the-loop MPC security e.g.
Prompt: "Make a private transfer of 1000 USDC to Gill on Ethereum"

Railgun protects against fraudulent activity with its Proof-of-Innocence. We believe in privacy as a human right, but do not want to enable crime.

Every KeyGen Ethereum address gets its own 0zk address and users can shield, transfer and unshield assets as easily as for on-chain transfers, using either our great UX, or in the custom AI harness.

The KeyGen's private notes are securely stored on the MPA Wallet's node.

For complete privacy, use the built-in @AskVenice LLM connector for MPA Wallet, alongside the off-chain signature generation that comes with MPC.

Enjoy!

We have already showed how using multiple nodes with MPC is good for BTC custody, but here is how Multi-Party Agent Wallet's built-in AI agent can prevent a transfer nightmare.

Optionally use a pruned Bitcoin Core blockchain on your node for extra security. MPA Wallet makes this easy to add this if you have 100GB of space.
Prompt: "Send Tom 0.1 BTC using extra security".

On EVERY node involved, even without Bitcoin Core, the AI agent will check the address you are sending to, ideally one stored as a Contact on your node, to make sure the amount and recipient have not changed. If you do not trust any third party bitcoin node, then host a Bitcoin Core yourself on one of the nodes in the signing set. Then the agent also checks that there can be no conflicting spend (forces re-broadcasting if necessary). On Execute, the signed transaction is submitted through that Bitcoin Core. The payment is recorded as sent only after the transaction is in that node’s mempool or already confirmed, and the recorded transaction id matches the signed transaction.
If anything is wrong IT STOPS.

Multiple signing parties + AI checks against your local Bitcoin chain set.

This article explores how the MPA Wallet stands up in terms of security to other wallet types, excluding hardware wallets for now (this is a separate analysis).

MPA Wallet uses the MPC algorithm with key shares on different nodes (computers) to make signatures that can be broadcast on-chain. These nodes could be run by humans, by AI agents or both. The Agreement ceremony generating the Private Key happens off-chain. No other entity, company or database is involved in this process.

The main other types of wallet are:

• On-chain multi-sig (e.g. Safe) puts the policy in a contract. Every signer still holds a complete private key, usually in a hot wallet.
• MPC browser extensions with a vendor share (the 2-of-2 cloud co-signer model) never give you a full key, and never let you sign without the vendor. The second share could be OAUTH, like email, or sit in a vendors database.
• Simple browser extensions that hold the Private Key (MetaMask, Rabby, Phantom, and the same pattern) put the entire wallet in one browser profile.
• Paper wallets put that same entire key on paper. Spending means typing it into software.

Before we start, let's define 'parties', 'threshold', 'shares' and 'batch sign requests'.

For MPA Wallet and for multi-sig wallets, we talk about 'parties'. This means nodes for MPA Wallet, but simply different signers in the case of a multi-sig. For MPA Wallet, each party has a 'share' of the Private Key, or more accurately, the ability to generate it. For multi-sig, each party needs a Private Key. We also talk about 'batch sign-requests' for MPA Wallet. DeFi rarely wants one signature. These are collections of multiple signatures to be signed at the same time, as is a common requirement when interacting with a web3 protocol. The 'threshold' is the number of parties that must 'Agree' to signature or batch sign-request before it can be executed on-chain, so a threshold of '2/3' means that 2 parties must Agree out of a possible 3.

This article compares the different wallet types in terms of security in interacting with DeFi. Let's take it step by step.

Where the secret lives

MPA. Threshold shares on nodes you deploy. No full Private Key on any machine.

Multisig. Each signer holds a complete Private Key. The payload is in a contract.

Vendor MPC. You hold one share. The vendor holds another in their infrastructure.

Extension. The full private key lives in the browser profile.

Paper. The full private key is on the paper, or in a photo of it.

Who can spend alone

MPA. Only if they already meet the threshold you chose (2/2, 2/3, 3/5, …).

Multisig. Only if they meet the contract threshold. A stolen signer key is still a complete secret.

Vendor MPC. You cannot. The vendor co-signs every spend, and can refuse.

Extension. Yes. The key, the seed, or an unlocked session spends the wallet.

Paper. Yes. Anyone holding the paper spends the wallet.

Is a company on the signing path?

MPA. No. ContinuumDAO does not hold a share. It is decentralized.

Multisig. No, inside the contract. Each signature still comes from a hot wallet. Also decentralized.

Vendor MPC. Yes. Every signature needs the vendor. Not decentralized.

Extension. The extension is the signer. A bad update or a malicious lookalike build is the wallet.

Paper. No, until the key is typed into software.

If that company ceases operation

MPA. Nodes you already run keep signing. No more software updates. Can Eject to a full Private Key.

Multisig. The contract remains. You still need the signer keys and a way to submit.

Vendor MPC. Signing stops. The share you hold is not a wallet.

Extension. The seed imports into another wallet.

Paper. The paper still spends, once imported.

What the chain sees

MPA. One ordinary signature from the shared address.

Multisig. A contract wallet. Signer set, threshold, and approvals are public, and every call costs extra gas.

Vendor MPC. One ordinary signature.

Extension. One ordinary signature.

Paper. One ordinary signature, after import.

Protocols that expect a normal account

MPA. The address is a normal account.

Multisig. Some protocols reject contract wallets or price them differently.

Vendor MPC. The address is a normal account.

Extension. The address is a normal account.

Paper. The address is a normal account, after import.

Who approved

MPA. Proposals, Accepts, and Rejects stay on your nodes. The chain sees the transaction.

Multisig. The signer set is public. Executed approvals are often public too.

Vendor MPC. The vendor sees every signature. The chain sees a single signature.

Extension. There is no second approver.

Paper. There is no second approver.

One review for a batch

DeFi rarely wants one signature. It wants an allowance and then the call that spends it, or a deposit and then a stake.

MPA. One multi-sign request holds the whole sequence. Co-signers can only Accept the whole batch, then MPC signs that payload. Broadcast sends the transactions in order, as ordinary account transactions.

Multisig. Safe-style wallets can pack calls into one atomic contract execution, so a revert rolls the whole bundle back. That atomicity is real. It is also a contract call, paid for in gas and in protocol support, and each signer still approves with a hot key.

Vendor MPC. One prompt per transaction. Approve and the next call are separate clicks.

Extension. One prompt per transaction. The dApp can change calldata between the screen and the signature. The gap between the approval and the following call is the dangerous part.

Paper. Not a workflow. Each spend imports the key.

Checked before anyone is bound

MPA. Per leg: function signature, parameter types, names, destination, and chain. The request is posted only after that check.

Multisig. Whatever the UI or a script checked. A bad call reverts on-chain after signers have approved.

Vendor MPC. A vendor warning on a single transaction, if they built one.

Extension. A single-transaction check inside the popup, in wallets that offer one.

Paper. None, until import.

Simulated on the live chain

MPA. Each leg is simulated from the MPC address against the chain you named. Later legs run on top of earlier legs in the same batch, so a revert in leg two shows up before anyone signs. At signature generation time, sequential eth_simulateV1 is what the gas figure follows.

Multisig. Some UIs simulate. Atomic execution rolls a failing bundle back after signatures are collected.

Vendor MPC. A preview of one transaction, if the vendor built one.

Extension. A preview of one transaction, in wallets that offer it. No co-signer re-checks a batch.

Paper. None.

Accept is bound to the exact payload

MPA. Co-signers Accept the published batch: calldata, recipients, amounts, Purpose. Agreeing nodes recompute EIP-712 digests and reject a mismatch. MPC runs only for that payload, which cannot be altered.

Multisig. The contract executes the approved hash. The member key that produced the approval is still phishable.

Vendor MPC. The vendor co-signs what the extension submitted. The extension screen is the trust boundary.

Extension. The screen and the signed bytes can diverge: permits, typed data, a swapped recipient.

Paper. The import step is the trust boundary. After that, software holds the key.

An AI agent, without a spendable key

The harness is a node, not a key. It can draft a trade, pull a protocol tool, post a multi-sign request with a Purpose, and read Thoughts from the other nodes. Purpose, Thoughts, and the transcript stay encrypted on the nodes you run, so the next AI agent on other nodes reads your history.

MPA. The harness runs on your node. It proposes with Purpose. Co-signers answer with Thoughts. MCP and the node API are the interface. History stays encrypted on your nodes.

Multisig. An agent that can act must hold a signer key, a module, or a session key. That key is a full secret.

Vendor MPC. An agent credential is co-signed by the vendor. Policy and uptime belong to the vendor. They can freeze it.

Extension. An agent with the key is the wallet.

Paper. It cannot propose, sign, or trade.

A human gate on every agent action

A typical personal group is 2/2. The agent can be fast. It cannot finish a signature alone. The same gate covers trades, governance votes, and treasury moves.

MPA. The threshold is the gate. A 2/2 group lets the agent propose and requires your other node to Accept. The frontend app still works with the agent turned off.

Multisig. Possible when signers are different people who read the payload. Easy to collapse into one person with several hot keys.

Vendor MPC. The vendor’s policy engine, not a co-signer you chose.

Extension. A popup.

Paper. A person holding the paper.

DeFi without exporting the key

MPA. Built-in flows for Uniswap, Aave, Curve, Aerodrome, Compound, Morpho, GMX, Hyperliquid, Derive, Lido, and others, under the same Accept loop.

Multisig. Safe apps and WalletConnect, signed by member keys.

Vendor MPC. The extension’s dapp browser. The vendor co-signs.

Extension. Native, and the widest dapp list. Every site can request a signature.

Paper. Sweep into a hot wallet first.

Bitcoin and EVM, same custody

MPA. Bitcoin (SegWit and Taproot) and EVM from the same group. ECDSA uses CGGMP24. Ed25519 chains (Solana, NEAR, and others) via FROST are on the rollout. MPA can work with almost any blockchain. Works with any EVM automatically.

Multisig. A different contract, or a different tool, per blockchain.

Vendor MPC. The chains the vendor shipped.

Extension. A different extension, and a different key, per ecosystem.

Paper. One chain and one address format.

One lost device, or one person

MPA. Extra nodes and a threshold you choose. Encrypted node backups restore a node onto new hardware. Family or friends can hold shares.

Multisig. Works when the signers are actually independent.

Vendor MPC. Recovery is the vendor account: email, phone, or KYC. A lock on that account freezes the wallet.

Extension. The seed is the whole wallet.

Paper. Fire, loss, or an heir who cannot find it. An heir who finds it can take all of it.

Phishing when you spend

MPA. Reviewers see a request already published to the group. They are not connected to the dApp. All off-chain.

Multisig. Each signer’s hot wallet is a target. One compromised signer lowers what remains of the threshold.

Vendor MPC. The extension and the vendor account.

Extension. The product itself: every site, every permit, every blind sign.

Paper. Low in a drawer. Total at the moment of use.

What you actually run

MPA. One or more nodes, on a machine or a VPS you control.

Multisig. A contract, plus a hot wallet per signer.

Vendor MPC. An extension and a vendor account.

Extension. An extension.

Paper. Paper, then a hot wallet whenever you spend.

I think that it is worth acknowledging that on-chain multi-sig can do something MPA Wallet does not: pack the same calls into one atomic contract execution, so a revert rolls the whole bundle back. That atomicity is real. It is also a contract call, paid for in gas and in protocol support (someone has to write and deploy this function), and each member still approves it with a hot key.

MPC wallets that are browser extensions and that have a vendor-share and private-key extensions ask once per transaction. The dangerous gap, where attacks can happen, sits between the approval and the following function calls. Paper wallets simply cannot have such a problem, since they have no batch of signatures at all.

Multi-sig wallets still leave a full private key with every signer, and they publish the policy on-chain. MPC extensions that keep a vendor share cannot sign, recover, or survive without that vendor. Browser extensions that hold the private key, and paper wallets, put the entire wallet in one secret. MPA Wallet keeps threshold shares on nodes you deploy, reviews a whole batch before anyone signs, simulates that batch against live chain state, and lets an agent propose through a harness that cannot spend unless your other node(s), whether they are run by humans or AI agents, Accept. Maintaining a cryptographic break between what an AI agent can sign without Agreement from other nodes is the defence in depth that is most sorely needed today as we see AI agents breaking out of their jails.

The price you pay for MPA Wallet security?

You must run multiple nodes on different machines.

Recently there has been a lot of anguish "How can I safely store my Bitcoin?"

For a long time we were told that a hardware wallet was the safest option, with recommendations to keep the Private Key on dedicated hardware, away from an internet connected device. But then we had incidents of hacked databases of buyers' personal details, painting a big target on holders' backs and who are now waiting for a wrench attack. Or maybe users cannot update their hardware device to the latest firmware? Or maybe the screen digits are fading on their screens? Or recently, the hardware of the device actually transmits the key to a malicious actor! And of course you STILL have to save the seed phrase somewhere.

So then some advocate only ever using a Cold Wallet and a PC that is only ever exposed to the internet for one purpose. A dedicated PC, but who is going to do that? We are told that we have to do this, because one bad browser injected widget can drain all funds, or address poisoning/substitution can send your BTC to a malicious address. Even with a dedicated PC, what about the Private Key? Should that be memorized? What happens in the case of age related mental infirmity, or in the event of an accident? OK, so you have to write the Private Key down. Should multiple copies be kept? and where? What about fires? In a safe deposit box?

Finally some are saying the unthinkable - that holders should use large custodial centralized exchanges instead of self custody for BTC, which is anathema to many of us and a complete betrayal of our principles.

There is another way though

Set up ContinuumDAO's MPA Wallet with a Group on 2 or more nodes. Create a KeyGen (secp256k1 key for SegWit, or a Schnorr key for Taproot). The KeyGen has a public key, but NO PRIVATE KEY. The KeyGen has a Threshold parameter, set by every node in the Group. The Private Key can only be created collectively by at least a Threshold number of keys using the Linux Foundation's Lockness project's Multi Party Computation using state-of-the-art CGGMP24/FROST. The Private Key itself is never exposed.

So now one node initiates sending some BTC to another address (using a stored Known Address of course!) with a Sign Request and some text stating the Purpose of the fund movement. Other nodes in the KeyGen see this SignRequest and the AI harness on their node can optionally check the destination address and Purpose. They can either Reject the transfer, or Accept it. When a Threshold number of nodes have Accepted, the originator is allowed to construct the signature and execute the transaction.

Why is this better than other self custody solutions?

• Unlike almost every other MPC wallet, there is no custodial element in ContinuumDAO's Multi-Party Agent Wallet. ONLY the nodes can sign and there is no rescue key, or OAUTH login etc. You are responsible for making a setup that allows you to recover from a disaster. Happily this is easy with MPA Wallet.
• The software on the nodes is installed by whoever controls each node. No other software is required. Even the application interface is run from software on the node. If ContinuumDAO ceased to exist, the software would continue to run. Software updates are discretionary, but never required.
• The simplest Threshold Signature (TSS) is 2/2 i.e. both nodes in the Group of 2 must sign. A TSS of 2/4 means that any 2 out of 4 nodes in the Group must sign, so that 2 nodes could be used as backup, or be accessible by trusted individuals, for disaster recovery.
• Privacy is paramount. There is no sign-up. No personal details are collected, nothing is sent by post. This is a software solution.
• Everything is encrypted, including communications between users and nodes using ssh tunnels and between nodes using TLS.
• Nodes can be backed up with their databases being encrypted using each node's unique Ed25519 Bootstrap Key. An encrypted database can be stored safely somewhere separate from the Bootstrap Key and then if the node is lost for whatever reason, it can be later recovered. Even if the encrypted database and Bootstrap Key to unlock it are both stolen, they are not sufficient to steal funds, since other nodes would have to be compromised too, due to the MPC TSS algorithm.
• Address poisoning or a wrench attack? No funds move without a Threshold signature from multiple nodes.
• Pieces of paper with seed phrases hidden around the house or in safe deposit boxes? Not required. There is NO PRIVATE KEY with MPC.
• No need to register SSL certs for nodes, thus preserving privacy.

Believe in self custody again. Ask you AI agent to "Install ContinuumDAO's MPA Wallet" on your machines.

Free to use this month and always with staked veCTM
Ask your agent to "Install ContinuumDAO Multi-Party Agent Wallet" on 2 or more nodes
An AI first DeFi experience and a node based and completely non-custodial decentralized MPC wallet for Bitcoin and EVM chains

• No Private Keys. Uses state of the art CGGMP24 and FROST MPC architecture, with Threshold signatures.
• No custodial key material. You need 2 or more nodes in Groups to make signatures. Each node can be run by AI agents, humans, or both.
• Human-in-the-loop cryptographic protection for AI trades.
• Runs on a VPS, or a home PC with Windows, MacOS, Linux (Ubuntu/Debian/Arch/Omarchy/Fedora/OpenSUSE).
• Custom AI harness designed to work with 21 of the most important DeFi protocols with an enormous and growing toolset. Supported to date:

@aave
@HyperliquidX HIP-3 Perps and HIP-4 Outcomes
@RobinhoodCrypto and @arcus_xyz
@Morpho
@Uniswap
@CurveFinance
@LidoFinance
@ethena
@eulerfinance
@aeroxyz
@Compound_xyz
@pendle_fi
@maplefinance
@SkyEcosystem
@GMX_IO
@DeriveXYZ
@Trueo_
@circle CCTP
@AskVenice
@ContinuumDAO

• AI driven candlestick charting and indicators.
• AI driven Technical Analysis, building trades directly.
• Private VPN, for nodes with staked veCTM.

Join our DAO for personal assistance, or simply ask your agent about ContinuumDAO MPA Wallet

@Apxymous We certainly will use the allocation from departed core contributors if this proposal passes. We will have a vote at TGE to decide how much of the CTMDAOVOTE tokens convert to veCTM and therefore how much ex core contributors will receive, but in this proposal, it is suggested that it will only be a small amount, capped at 0.1% (100k veCTM).

@Apxymous Hal did the smart contracts part and he is developing the Governance frontend at the moment. He may incorporate a newer version of the staking into this new Governance frontend

We are currently offering the VCs tokens at a Fully Diluted Valuation of 20 million USD, so each CTM is equivalent to 0.20 USD. Hopefully the value will increase to 1 USD and more after TGE, but those helping to build our products now deserve the same terms (in my opinion).

Arkman has worked for more than 1 year on the frontend for AssetX, as well as the homepage for ContinuumDAO, the C3Caller page, the MPC Dashboard and the veCTM Staking page. So far he has only been paid less than 5k USD in total. He believes in the project and I will certainly vote in favour of awarding him 500k veCTM now and another 500k veCTM at TGE, assuming that he continues working as he has been (I am sure he will). Regarding Lex, our new legal web3 expert - we cannot successfully launch our RWA Security issuance platform without his experience. Securities are heavily regulated and our existing DAO core contributors have no experience in legal matters. He is also advising us on incorporation and he came to us with his excellent idea for Lawracle that will benefit us all. I will certainly be voting to give him 500k veCTM now and another 500k veCTM when we go to mainnet with Lawracle. Let's keep the big picture in mind. We need Arkman and Lex in our DAO.

@sanderrrrr Per contributor. We should make this clear

I would like to include application for the Dubai DFSA Tokenisation Regulatory Sandbox. See the details here https://www.dfsa.ae/innovation/tokenisation-regulatory-sandbox

If ContinuumDAO is successful in its application, we would need to apply for a Dubai license in addition to the RAKDAO license, but I think that if we can afford it, it would be very beneficial

@avgCrypto I think that it might be true in Dubai, but the process seems simpler in RAK

@rebe2a @motki Any community sale would follow TGE, securing a license and would have to conform with regulations and follow legal advice. This would be the subject of a separate DAO proposal.

@sanderrrrr No need for any of us to move there (though RAK does look beautiful). We would need to secure a crypto trading license when we launch our token and the Middle East and especially the UAE could well be where we grow our business fastest initially, so it is nice that we have the option of making this a base, with people possible in the future.

@Raini-Ng Crowdfunding is an option, though we need assistance from someone who has experience in organising this. The real funding issue is that we need money for the code audit and listing on a CEX before we can go to mainnet and this could be a substantial amount, even if we limit the code we audit to MPC code, C3Caller, veCTM. Unfortunately this is not cheap and is why Jerry mentioned the figure of 1 million. Let's see how our new deck and RWA focus goes down with VCs.

@avgCrypto Completely agree with you about creating manageable goals. Thank you!

To be clear - we won't get VC funding unless we present a UNIQUE and INNOVATIVE proposition for funding. They are interested in backing the next unicorn, not another cross-chain interoperability protocol. We may get some backing from other sources such as DAOs, crowd funding and private funding, but I'm not sure we will get 1 million USD.

Regarding performance across market cycles, let's not forget that stable coin based RWA strategies are favoured in bear markets.

Regarding whether we should explore other avenues than VCs for funding, I think that we need to now, since our funds are so low. This could include a private sale, or crowdfunding through another DAO or company. Let's explore this.

Continuum was founded as a DAO for very good reasons (we all know about what happened to Multichain). Being a DAO and having exclusively open source code is the only alternative to a centralised company led project and for me this is non-negotiable.

But having spoken to a large number of VCs over the last few months, I do not think that this is the issue at all. In fact if a VC is looking for a preferential token allocation on different terms from early investors (i.e. a 4 year lock of veCTM with voting rights), then this for me is a huge red flag. They likely want to do a quick 10x from Seed to Series A and dump on retail as exit liquidity. If a VC believes in our long term vision, then this would not be an issue. But like I said - I think that other factors are in play

Typically this is how the conversations with VCs have gone in the past - I emphasise that we are building a public good for web3, with no central control and as a trusted base layer for cross-chain dApps. This does not get a strong reaction (neither hostile or positive). Sometimes they will point out that there are other solutions (L0, Axelar etc.). They simply don't care that we are Autonomous and have no central control. I then point out the security advantages of MPC, but again this does not bring a strong reaction. Usually they simply don't know what MPC is and I do not have enough time with them to explain it. I say that we are integrating non-EVMs (TON, NEAR, Solana, SUI). This is more interesting to them, since we are entering unploughed ground here, but not enough. I say that we have incubated an open source router, but some say to me that the profit margins are not very good anymore and that there is a lot of competition in this sector. The feeling I get is that this was the last bull run's narrative.

So I don't particularly agree with your analysis @Insomniac The main issue is that we need to align our goals with TODAY's narratives.

Recently I attended ETHCC in Brussels. I went to many side events. By far the most exciting one was the RWA event. There were many new RWA protocols, VCs and tradFi representatives there (e.g. Stripe, VISA). The packed audience were voting on how long it would take the next 1 trillion USD of tokenized RWAs to arrive. The consensus was 18 months. There was much discussion about how tradFi could increase their profit margins by a few percent by cutting out middle men using DeFi. Also there was agreement that RWA was much more immune to bear/bull market cycles, since investors typically use USD stable coins. Several panellists said that almost all alt coins would die, that retail would only hold stable coins and that mass adoption of blockchain would not come from the 'casino' of trading alt coins, but only through more sober investing though useful investments such as :

• SME loans
• Invoice financing
• Fractional tokenised assets such as real estate, rental properties, commodities (including gold)
• Bonds
• Securities (e.g. equity)

Interestingly (and this is where i think that our opportunity lies), some panel contributors talked about how early block chain was in this field and how the solutions still do not exist in DeFi, leading to prohibitive costs for participants, poor access to liquidity, regulatory challenges, poor user experience with wallets and more.

When I got back from ETHCC, we started to develop a deck that re-focused Continuum towards RWA. Here is the link to it and I would value your views on it : https://docs.google.com/presentation/d/1-5FEB905Ff54cDkKnkauCilbT8OQdWU0Rn2u29JVYbE/edit#slide=id.p

We have sent this new deck to some VCs and I would say that the feedback is quite good, but it is early and as Insomniac points out, it takes time for the discussions to bear any fruit. I think it is fair to say that not all contributors believe that we should pivot 100% to this new narrative, rather than maintaining that we should address ALL sectors (e.g. GameFi, AI, liquidity aggregation etc.). I think that we should pivot with COMMITMENT now and focus exclusively on bringing RWA products to RETAIL investors by creating cross-chain solutions to cheaper faster blockchains like TON, Solana, NEAR and SUI - playing to our strengths. What do you think? Please read the Deck and comment here. Some feedback we have got is that this is aspirational and that we do not have our new RWA Toolkit yet. We are in the same boat as Axelar and Wormhole here - no one has developed solutions yet, so it is a race. This tells me that we are in the right direction though. We need working Proof of Concepts for things like fractionalised cross-chain NFTs for assets and the ability to access RWA vaults on Ethereum from non-EVMs etc.

@Arafat Thanks! It is complicated but fair. We gave this a lot of thought