veCTM and C3Caller Development Updates

[Jerry]

veCTM

Purpose:

The veCTM token contract was described in the Treasury proposal, which was passed on the 17th Nov. 17th 2023 veCTM proposal

Design/functions:

Progress:

Updates
The code updates are in the public repository on Github.
The original schedule was that by the end of the first month two milestones would have been met: veCTM contract (proxy pattern, escrow, liquidation, merging, and splitting) and MPC node attachment feature. The final milestones were: modified OpenZeppelin Governor contract, functional frontend and token distribution.

It became apparent during development that it was worth developing the Governance functions at the same time as veCTM development and leaving the MPC node attachment until the MPC network is ready. This means that some elements of milestone 3 are complete but milestone 2 will need to await deployment of the MPC network.

Currently, the veCTM uses a transparent upgradeable proxy pattern, consistent with ERC-1967. This means the logic contract can be upgraded and additional storage can be appended. The approved upgrader address is a proxy admin, controlled by the Governance contract. The features included as of now are an NFT and the voting escrow code. The interface to Governance is included with vote counting consistent with the Escrow vote power, however, it is not yet fully implemented - this is where most of the focus is right now. This includes situations such as counting voting power for users who have multiple veCTM NFTs, or who had multiple NFTs at a historic timestamp of interest.
Merging of veCTMs is implemented, and splitting and liquidation are in development.
Many tests are yet to be completed.

Issues
Excluding day-to-day issues that are encountered with developing any project of this complexity, there are currently no major outstanding issues that require external attention or concern.

One issue which was encountered recently involved deciding how to count a user's voting power at a historic timestamp, where they potentially had multiple NFTs, which they may no longer have. The workaround was to use a checkpointing system where each token transfer is recorded and factored into vote unit counting. This feature is taken from NounsDAO.

It is still unclear what exactly the interface to the MPC node network will be, or what is required.

Solutions
Regarding the MPC node network, further communication will be required with Grubby to ascertain the interface details and an examination of a more final version of the MPC node code, to design the MPC node attachment code in veCTM.

C3Caller

Purpose:
C3Caller is the first cross-chain messaging application on the MPC network, and also the first use case for CTM. Since cross-chain messaging already includes token cross-chain and has a simple fee structure, we hope to integrate more Dapps with C3Caller. Therefore, we are currently abandoning the functions of C3Router to keep our system simple and easy to maintain.

Fee:
Fees are simply charged based on the length of the message using a configured token. Upper-layer dApps, such as a router dApp need to pre-deposit a certain amount of specified tokens. After the cross-chain is completed, fees will be automatically deducted. The specified token can be USDT, CTM, etc.

Progress:

Updates
1. The contract part was completed, targeting the most basic cross-chain messaging.
2. Development progress of C3Caller-relayer service is at 80%, first supporting EVM chains

[Selqui]

Well done to all involved in the coding. I think that we are broadly on course.

[sanderrrrr]

Happy with the progress!

[Arafat]

Really cool to see the progress on the veCTM contract and C3Caller. Good how you guys are handling the vote power issue with checkpointing!

[Selqui]

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

[Gloomy]

Progression is crucial to achieving something remarkable.