We need to think of a good way to charge for our services. Whatever we do should be properly decentralized, so we do not have to rely on individuals to collect fees, swap between many different tokens, charge smart contracts with fee rewards etc. Ultimately we want collected fees to appear automatically in a fee distribution smart contract as CTM.

I have collected the thoughts from the Telegram chat and add my own here. Please contribute to the discussion in this thread.

C3Router

To avoid having to collect fees in hundreds of different volatile tokens and convert them to CTM, we could charge a flat rate of (say) 10 USDC (more for transfers to Ethereum) for every transfer. This would be on top of gas on the source chain, but would pay for the gas on the destination chain. We partner with a DEX on every source chain to provide gas coin/CTM liquidity. The user has the following options to pay for the transfer (examples when Ethereum isn't the destination chain) : 10 USDC, the equivalent amount of gas as 10 USDC, or 10 CTM. This final option of paying in CTM should allow users to make a small saving.

Within C3Router, there are functions that interface with the AMM of the partner DEX (interface to Uniswap functions) to calculate how much gas is equivalent to 10 USDC, converts 10 USDC to CTM, converts gas coin to CTM and a function that sends the CTM to a Treasury contract for fee distribution.

C3Caller

The fee mechanism would be the same as for C3Router, but this time we charge a fixed amount of USDC or CTM per byte of data transferred. Something like 0.01 USDC/byte , or 0.01 CTM/byte seems reasonable to me, unless the destination chain is Ethereum. This mechanism would apply for both payment on the source chain, or the destination chain.

I like the simple marketing message - cross-chain transfers cost 10 USDC, or 0.01 USDC per byte. Really easy to explain to anyone.

The numbers in the example table were arrived at after discussions with some VCs. My own feeling is that we offer CTMDAOVOTE tokens as soon as an investment is made and that these would be convertible 1 CTMDAOVOTE == 1 CTM vested in a veCTM for 4 years, with full voting rights with our TGE. We should not make sales to any person of USA citizenship or residency, any US business, or any person or business in any other proscribed or sanctioned country in line with other recent crypto funding initiatives. I see our series 'A' Fully Diluted valuation at about 400 mm USD at a stage when we have ~100 blockchains connected, several hundred MPC nodes, audited contracts and code, mainnet launched and healthy initial traffic and revenues. We could offer 10% of the Total Supply at this valuation, but that is the subject of another DAO proposal when the time comes. We could launch our token along with the series 'A', together with CEX listings and DEX liquidity.

Many thanks @hal0177 for this proposal. Would it be possible to associate images with empty veCTMs? That way we could auction them and holders could merge their existing ones to them. It could be a source of revenue for the DAO and a bit of fun.

We could enable minting of empty veCTM's from our front end at a cost of say 0.1 ETH (or 200 CTM?), or we could issue a collection of them and sell them on OpenSea, with the revenue going to the Treasury.

@John-CTM We should only sell as many tokens as we need to at this lower valuation to fund ourselves until we can offer a seriously attractive series 'A'. The figure in the table is for 2.5%, with gradually increasing valuation. Note that the suggestion has the sale of the final part spread over 3 months, approaching the mainnet launch. Another objective of this seed round is to attract early stage VCs, who would be able to guide us through the series 'A', as well as other communities (e.g. investment DAOs), who could dramatically increase our community.

We have learned the lessons from Multichain - No centralization (DAO run), and an open transparent MPC node network, run by the community.

Other pain points from Multichain have also been addressed, such as stuck transactions. These were caused by lagging RPC gateways (we will use the current best from a selection of them at any time), nonce errors (we will implement code in the MPC layer to revert these), faulty MPC nodes (we will allow switching to other better performing nodes and have parallel execution of signing).

Our aim is to be the gold standard for cross-chain interaction.

I wish to nominate myself for election to the new committee

This vote passed with 99.7% in favour. We are in business!

Let's work on a proposal to recommend payment for commissioned services to ContinuumDAO.

We need a framework so that contributors can know what to expect for payment and also what to ask for in their proposals for funding. Obviously exceptions would have to be made, depending on circumstances, so these would simply be guidelines.

These are my thoughts on how to proceed :

(1) Allocate 1 million CTMDAOVOTE tokens from the CTMDAO Treasury for contributors rewards.

(2) For non-coding work, for an 8 hour day, the rate of pay would be 150 USDC + 75 CTMDAOVOTE. This category would include design, marketing, business development, documentation writing, proposal development for grants, admin functions.

(3) For coding work (e.g. front end, but not smart contracts), for an 8 hour day, the rate of pay would be 225 USDC + 100 CTMDAOVOTE

(4) For coding work (smart contracts), for an 8 hour day, the rate of pay would be 225 USDC + 200 CTMDAOVOTE

(5) All commissioned work (i.e. a core contributor or Guild Leader asked for this work to happen) would have to be documented in time sheets, unless covered by separate funded proposals. Work of part of a day would be funded pro-rata by the number of hours actually worked.

(6) Payment would be made by the end of the month.

Let's work on the ideas for a proposal here that we are confident will pass. Please add your ideas below

@0xCTMC Point taken. Let's re-evaluate

ContinuumDAO Constitution Proposal

Created time: September 21, 2023 12:00 AM

ContinuumDAO Introduction

This document is the Constitution of ContinuumDAO (CTMDAO).

CTMDAO will consistently leverage the benefits of DAO governance and the unique features of MPC to ensure the stability and security of our network called the Continuum. Some of the rules and procedures in the Constitution will be enforced by voting and it is only by voting that these rules can be changed. Voting can take effect through on-chain governance and smart contracts, or the outcome will be implemented by the ContinuumDAO Committee.

Mission & Vision

Mission:

The mission is to create public goods that connect all web protocols and networks in a decentralized manner.

Vision:

Our vision is to connect the world by building the public goods of web3. We aim to provide a fully decentralized MPC infrastructure that enables dApps on different blockchains to connect, with trustless coordinated decision making.

ContinuumDAO Governance Structure:

There will be three governance roles: Committee, Contributor, and Citizen.

• The Committee will commit to uphold the ContinuumDAO Constitution. They will be responsible for signing transactions in multi-sig wallets that will perform admin functions and asset transfers, or other actions as directed by DAO voting. They will be the custodians of the important security information of CTMDAO. They will be responsible for submitting proposals that have passed a Temperature Check to a Formal Vote snapshot in a timely manner.
  • For the beginning of the CTMDAO, some previously active community members have been selected who have a good track record of contributing to the DAO. Their term will be for 6 months, starting from October 1st 2023. Thereafter Committees will be elected every 12 months. An election of a new Committee will take place and be completed before every 1st April, the expiration of the term of the old Committee. If a vote for a new Committee does not reach the quorum or required majority, then the old Committee will stay in place and a new election will be implemented as soon as practical.
  • Committee List：

Name
Selqui
Apex
JB
Apxymous
John CTM
Jerry
Chookz

• Contributors will include node runners, Guild members, and the core-contributors group.
  • The Contributors will be responsible for all operational tasks of the Continuum as well as future ecosystem projects that may need help. There will be four Guilds to assist CTMDAO, namely Research, Marketing, Business Development, and Developers.
• Citizens will have the right to join all governance processes, which include proposing, voting, and making contributions.
  • veCTM holders who will have full governance right in the CTMDAO.

The ContinuumDAO Forum

The Forum is a Bulletin Board hosted by CTMDAO on its website at forum.continuumdao.org . It is the official record of the proceedings of ContinuumDAO. All business concerning the DAO will be documented here, including proposals, Committee proceedings, Treasury asset transfers and Guild actions.

The Forum will be divided into five sections: Announcements, Ideas & Suggestions, Governance, Code Development and Guilds.

• The Announcements section is where important updates about ContinuumDAO will appear. This is the main record of such events happening with the protocol.
• The Idea & Suggestions section is a place for all DAO members to share their thoughts on ContinuumDAO and the cross-chain industry. It is a place where ideas can be formed into proposals.
• The Governance section is where DAO members can propose subjects related to the Constitution, the Treasury or project operations that require serious action. All proposals must be posted here.
• The Code Development section will be for DAO members with a development background to propose and discuss topics related to the code or bugs.
• Guilds section will be where focused actions are organized on behalf of CTMDAO. These invitation only areas will be split into the four Guilds: Developers, Marketing, Business Development and Research. Each Guild leader will be appointed by the Committee.

The Governance Process

All proposals will appear in the Governance section of the Forum. Every veCTM holder will have access to all Governance sections in the Forum.
There are only two steps of the governance process: Temperature Check & Formal Vote.

Temperature Check:

There is no threshold to propose for the temperature check. Proposals will have a temperature check for 5 days. Once they collect enough feedback (1/10 of the veCTM holders commented effectively on the proposal) from the community, the proposals can move on to the next stage, which is a Formal Vote.

Formal Vote:

The formal voting period for the snapshot will be 7 days. The governance for Emergency proposals will be shortened to 4 days. Only a Committee member can initiate an Emergency proposal. A Formal Vote needs to be submitted by a wallet address with at least 1% of the vote power before posting on the Snapshot. This can be accomplished via delegation if necessary.

A proposal submitted by a Committee member does not require a Temperature Check, but after having been posted to the Forum Proposal section, may be submitted directly for the Formal Vote snapshot.

The Temperature Check/Proposal Template:

• Abstract
• Motivation
• Specification
  • Overview
  • Type of proposal (Constitutional, Treasury/Committee, or Emergency)
  • Scope
  • Success Criteria (for Treasury proposals)
  • Timeline/Budget (for Treasury proposals)
  • References (for Treasury proposals)

A Citizen who wishes to make a proposal should develop it in the Forum Ideas and Suggestions section, before proceeding to posting in the Proposals section for a Temperature Check and if it passes this, they can then contact a Committee member or core-contributor to make the proposal go live with a Formal Vote.

Any proposal that is a re-submission should reference the previous proposal and explain what has changed from that version. If there is no material change from the previous version, then the proposal should not be submitted.

ContinuumDAO Proposals and Voting

Proposals should further the Vision and Mission of ContinuumDAO. If proposals do not clearly do this, then voters should seriously consider rejecting them. Every veCTM holder will be able to vote, with no threshold to vote, except holders of non-voting veCTM tokens. The quorum for the voting must meet 20% of the total voting power.

There will be three categories of proposal.

• The first is to change this Constitution. Any proposal that has an effect on it will be considered a constitutional vote. A proposal that will update core smart contracts, such as veCTM or SMPC related code will also be considered as a Constitutional proposal.
  • To amend the Constitution, a higher threshold of 67% is required.
  • Any Constitutional proposal that changes this document must include the new version of the Constitution. If it passes, then a hash of the document will be generated and it, together with the document itself and the code to check the hash will be made available on the ContinuumDAO github at https://github.com/ContinuumDAO.
• The second is for a proposal to spend from the Treasury, to elect a new Committee upon expiry of their term, to replace a Committee member, or concerning any other matter.
  • A voting result of over 50% of votes cast will pass the Treasury/Committee proposal.
  • A Committee election vote which alters the Committee will update this Constitution’s Committee and Multi-signers list without the need for a Constitutional vote.
• The third is for an Emergency proposal.
  • A voting result of over 50% of votes cast will pass the Emergency proposal.

Security/Emergency Procedure

An Emergency Procedure to halt the Continuum network can be performed by the Committee. A Committee member should try to contact other members, so that at least 4 members agree on a course of action, which must be discussed and documented in the Forum under the private Governance Committee section (not Telegram). If this is not possible due to an urgent situation, then it is acceptable for a Committee member to go ahead and halt the MPC network, either partially or totally, after which they must contact other Committee members as soon as possible and then document the reasons for their actions in the Forum Announcements section. The ability of the Committee to halt the Continuum network is a temporary measure, which will be lifted once the network is more mature. After this, it will only be possible to halt the network using on-chain governance controlled through voting.

No other Emergency procedure may be carried out by the Committee without a vote.

The Committee may squash the outcome of any vote, declaring it null and void if it obviously does not further the Vision and Mission of ContinuumDAO as laid out in this Constitution. To do so, at least 5 members of the Committee have to take this extraordinary action and then document the reasons for their action in the Forum Announcements section, including stating which members decided to oppose the vote outcome. Following this documentation procedure, if the proposal is re-submitted unaltered and if it once again passes, then the Committee may not squash the vote outcome for a second time.

Treasury

The Treasury is fully under the control of the voting process and the Committee may only spend Treasury assets as directed by DAO voting. The Treasury is protected by the seven CTMDAO Committee members in the table below.

Multi-signers list:

Name	Address
Selqui	0x167518826cba5c2180acc60E4753ee3e811a08e7
Apex	0x8A3D31028C8C83C407408193FF031e2DFD79E224
John	0x14C189354702b7f2aC7b19e61522A41632226BD8
JB	0x85e07b95213bc1c4d5a606c977d2116f8bcce811
Apxymous	0xA9108260723e5633137150d0950D0FF3f9a9222a
Chookz	0xd41B402D7FA1c00284AFf06c6771E6C179826F12
Jerry	0x80255a4a00CdDb1070DF85Be2407787199C43892

Safe-Wallets

Treasury wallets are multi-sig Safe-wallets. The threshold of the Treasury is 4 out of 7 signers.

The No. 1 Safe-wallet address is arb1:0x47B33679b7FF853300a5Cc19c59d85fcEBAaa278

Other Treasury Safe-wallets may be created in the future to assist in CTMDAO management and funds may be transferred between them, but they will follow the same rules as the No. 1 wallet and their addresses will be added to the Constitution as soon as it is convenient to do so.

Over time the use of multi-sig wallets will be progressively replaced by direct on-chain governance and new Treasury wallets will be created, whose spending will only be controlled by veCTM governance contracts. These wallet addresses will also appear in the Constitution as soon as it is convenient to do so.

ContinuumDAO ethics

• Security Access

  This concerns access to social media accounts, admin access to the CTMDAO github, admin access to all areas of the Forum, other key CTMDAO related websites and root access to VPS machines. Admin signing rights for smart contracts will either be via a multi-sig wallet under the control of the Committee, with the same requirements of 4 out of 7 signers as for Treasury spending, or by governance functions in veCTM. The relevant keys and passwords will be held in a Key Vault file, which will be updated as necessary.

  There will be different levels of access to information for different roles. The Committee will have full access to the Key Vault to ensure the security of the CTMDAO. The Committee undertakes to keep this information secret. When anyone from the Committee leaves, the keys and passwords will be changed. The spread of the Key Vault to all Committee members will ensure decentralisation. Contributors will have limited access to specific projects and accounts depending on their need. Citizens will have public access.

• Code of Conduct

  ContinuumDAO’s purpose is to provide a trustless and fully decentralized MPC infrastructure to connect the world.
  We welcome more web3 builders and partners to join our community, become contributors, and promote the prosperity and large-scale adoption of web3 trust layer.

  Our Commitment to the Code

  ContinuumDAO is committed to fostering a safe and collaborative environment regardless of gender identity and expression, sexual orientation, disability, physical appearance, race, ethnicity, religion, nationality, age, education, socio-economic status, or level of experience.
  This Commitment is written and shared in the spirit of creating a reliable standard for all members, contributors, partners, and communities associated with the ContinuumDAO.
  We invite all those who participate in the ContinuumDAO to help create safe and positive experiences for everyone.

  Goals of the Code

  The goals of this Code of Conduct are to set the overall tone for our community and to provide a guide and a process by which we interact and hold each other accountable.
  This isn't an exhaustive list of things you can and can't do. We want to cultivate a community environment that is healthy, open-minded, collaborative, and creative.

  Expected Behaviors:

  • Accepting constructive criticism gracefully.
  • Giving constructive feedback gracefully: Be direct, caring, and empathetic, express your thoughts on how well ideas relate to the common goal or aligned objective rather than putting them down.
  • Acting in the community’s best interest.
  • Being respectful of different viewpoints and experiences.
  • Participating in an authentic and active way. Contributing to the health and longevity of this community.
  • Using welcoming and inclusive language. Acknowledging preferred gender pronouns. Refraining from demeaning, discriminatory, or harassing behavior and speech.

  Unacceptable Behaviours:

  • Sustained disruption of community events and including public talks and presentations.
  • Organizing or participating in raids or other activities that intentionally disrupt community operations.
  • Implicitly or explicitly offensive comments.
  • Threats or incitement of violence of any kind.
  • Harassment, including persistent attempts to communicate with someone (publicly or privately) after requests are ignored or otherwise declined.
  • Using bots or other programs to maliciously manipulate ContinuumDAO’s contracts, events, products, content, social media account, Discord channels.

@toast I strongly disagree with this. I can accept that we need to offer our seed round at a low valuation to attract investors, but if we gave future offerings with a shorter unlock period, then these people could dump on early investors, the existing community and future retail holders. Our veCTM voting escrow contract has a 4 year lock, BUT it allows liquidation with a 50% penalty at the beginning, decreasing linearly to 0 after 4 years. So anyone can either sell their veCTM as an NFT, or liquidate at any time. Meanwhile they have voting rights and their veCTM gives them a share of the profits. This is very fair to anyone.

We need to attract investors who hold our long term vision, even if it means losing some potential investors, who would probably not be the right fit for us anyway. I will vote against any proposal to offer a shorter unlock period for investors.

@Ulliee Do you mean veCTM (subject of this proposal), or ContinuumDAO in general? The NFT is designed to enable governance, distribute protocol income, and allow holders to run nodes in the network. As far as Continuum goes, it's in the White Paper, but we hope to attract a lot of different enterprises to run their own cross chain routers, create multi-chain dApps, create MPC wallets and generally to join up the value systems that are all block chains - EVM's AND non-EVM's. The holders of veCTM will earn a small fee every time someone uses our network.

One of the reasons for offering at a low valuation to VCs in the seed round is that we don't only need their money. We also expect to leverage their network and their marketing reach to help us grow. Frankly, we don't get that with small retail investors. We also have to conduct KYC, which at this time is simply a burden to us. I'm not in favour of a retail offering at this point. There is a way for the community to get veCTM now though and that is to contribute.

@murchadh Thanks for bringing this up. We have two methods of executing governance - Snapshot and Tally. With Snapshot, a Committee member must post the proposal, but with Tally, anyone with sufficient voting power of 1% can do so and the result is automatically executed, so that in theory a malicious actor could submit and pass a proposal, which would drain the Treasury for instance automatically. The time delay gives the Committee an opportunity to stop this, since only proposals that do not 'further the Vision and Mission of ContinuumDAO as laid out in this Constitution' should be allowed to execute. This is a safety mechanism that many other DAOs also use.

The Constitution also says that 'if the proposal is re-submitted unaltered and if it once again passes, then the Committee may not squash the vote outcome for a second time'. This limits the power of the Committee to ignore the will of the DAO.

@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.

This information is also in our docs here :- https://docs.continuumdao.org/ContinuumDAO/RouterWorkingMechanism

The code is on github as a private repository, that will be made public in due course.

@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.

Router Working Mechanism

Nodes Structure

The relationship between C3Caller-Relayer and MPC can be seen in the above diagram. The C3Caller-Relayer node includes all the functionalities of the message cross-chain. It is highly available and scalable, with stateless nodes that do not communicate with each other. When performance is insufficient, it can be horizontally scaled. Currently, the plan is to deploy two or three nodes to form a cluster, relying on a MySQL database and Redis cache.

It is enhancing the current node services for high availability, scalability, and performance. The proposed system will include stateless nodes in a cluster formation, supported by a MySQL database and Redis cache.

• The C3Caller-Relayer node includes token and message cross-chain functionalities, offering high availability and scalability.
• Nodes are stateless, not communicating with each other, allowing horizontal scalability.
• Planned deployment of a cluster, relying on MySQL and Redis.
• RpcGateway supplies a union-high availability of blockchain RPC when C3Caller-Relayer requests. it always forwards requests to those with the highest Blocknumber of all the RPCs.

Contracts

The contract structure is shown in the above diagram.

• C3DappManager is Dapp manager Contract, which handles the pre-stored fees and Dapp register.
• C3CallerDapp is a entry point so if Dapp Contract extends it, it could call the c3call() method
• C3CallerProxy is a Upgradeable contract and holds an instance of IC3Caller so that we could upgrade C3Caller if a new version C3Caller comes.
• C3Caller is a real logic contract which have c3call c3fallback and execute
• The management rights of the contracts are generated using the MPC network.

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

@chookz The difference between the MPC nodes and the C3Caller-relayer nodes is as follows:

The MPC nodes are run by a separate protocol (ContinuumDAO), whose only purpose is to guarantee decentralized secure cross-chain signing in an open and transparent way. Members of the DAO will be able to run nodes and be rewarded for doing so. Running a node will be as easy as possible, with no programming knowledge required and with clear instructions. If the community finds it difficult to run the nodes, we will find a way to make it easier.

The C3Caller-relayer nodes are designed to be run by people with more knowledge of Linux. These will be run by selected individuals with the required skill set. The main reason to have more than one these types of node running is to provide redundancy. There is no signature algorithm in these nodes.
In the case where one node goes out of action, the servicing of cross-chain requests will revert to another node. This eliminates a key vulnerability that Multichain had. The C3Caller-relayer nodes will also handle new dApp integration and fee collection. The reason that they will do this is to keep the MPC nodes as simple as possible.

We are aiming to make it possible for multiple simultaneous cross-chain signings to take place, using different groups of MPC nodes, being served by C3Caller-relayer nodes. This means that our service can expand, with ever more MPC nodes and C3Caller-relayer nodes as required, with no reduction in speed during times of higher traffic. This flexibility will also ensure that problematic MPC nodes will not halt cross-chain services, as they sometimes did in Multichain, with much heartache.