c-layer/contracts

C-Layer Ethereum monorepo

Compliance Layer SmartContracts

Welcome to the C-Layer Ethereum monorepo.

Purpose

Provide an administrable layer over the Ethereum blockchain protocol.

One of the foremost use case is the support of regulated asset classes and financial services.

Content

This repository is a monorepos of the different component of the projects.

• Common: contains the core and security architectures among other utilities
• Oracle: contains an oracle
• Token: contains the token core, all token delegates, a token factory with their own default configurations
• Distribution: contains tokensale and vault contracts
• Governance: contains voting and multisig contracts

contracts's Issues

Test descriptions and test messages should be meaningful

If you see In tests any description or message which doesn't seem meaningful
then please suggest something which would be more meaningful to you.

Shareholders premption rights

Shareholders should provide a way to implement a premption rigths allowing shareholder to prempt at a fixed price shares.

TBD

Test

Voting contract should allow weight votes based on token hold by participants.

The existing TokenizedVoting is using the Proof mecanism.

It is to be seen if ProofOfOwnershipDelegate should be reintroduce or new mecanisms provided to access the token owned by an address/user.
In particular, a Stacking strategy may be used instead. Tokens are then locked into the voting contract and can only be recovered between votes. Should rewards or incentives be added ?

Once impacts are identified and validated, this issue needs to be splited into smaller implementable issues.

Suggestion to rename this repository into c-layer

Hi everyone,

Let's turn c-layer/contracts into c-layer/c-layer to endorse it officially as the main (and single) repository.

UserRegistry Extended Keys -> new data

Hello!

Extended keys (array of uint256) are presently used in the following way:

extendedKeys_[0] is the validated Tier
extendedKeys_[1] is the maximum accepted purchase amount in CHF
extendedKeys_[2] has reserved use for AML recovery

Could it be relevant to add two keys (non-personal data):

extendedKeys_[4] as a uint256 encoding the user's country of residence
extendedKeys_[5] as a uint256 encoding the user's nationality

Regarding encoding, first intuition was to use international phone country code (e.g. 41 for Switzerland) unfortunately some countries have the good idea to share codes (e.g. 1 for both Canada and the US). It looks more convenient to use UN codes or encoded ISO 3166-1.

I'm also thinking of other parameters which are useful in a user context:

• seeded hash of ID picture
• seeded hash of signed TPA (or digital signature)
• internal mongoDB identifier

Giving extra with another token

Possibility to add another token when create a basic tokensale for the bonus.

E.g sale token1 + bonus token2

Thanks !

Voting contract should allow the definition of voting rules (quorum, min participants, ...) based on resolution hash.

Currently exists only one governance rule (duration, minScore, quorum) at a time.
The governance rule is stored for each votes.

It is proposed to allow the definition of multiple governance rules which should be automatically selected at the creation of a new proposal based on the resolution hash (and other attributes, if needs were to be identified).
The rational is to have a different quorum and other rule attributes depending on the impact of the resolutionHash which will potentially be executed.

KYCOnly alternative to LimitableTransferabilityDelegate.

A simplified compliance delegate using the user registry as a whitelist.

The new delegate will offer an alternative to the existing LimitableTransferabilityDelegate. It will inherit OracleEnrichedDelegate and check the User Registry a valid for both sender and receiver but will not do any AML checks.

The new token delegate corresponding to CompliantTokenDelegate should include the other dependencies as well (Lock, Freeze, Seize, Mintable and RuleEngine). They do not consume much gas cost.

New names should be given to the corresponding LimitableTransferabilityDelegate and CompliantTokenDelegate. It is proposed to name them KYCOnlyTransferabilityDelegate and KYCOnlyTokenDelegate

Voting contract should allow hash execution based on vote resolution.

A new function execute(uint256 _proposalId) public returns (bool) should be added to the voting contract.

This function should execute the resolution hash when the vote is successful on a target contract.

In VotingCore, the storage should add an address targetContract field in the Proposal structure.

'hash' should be renamed for clarity into resolutionHash

Representing non voter shareholders during General Assembly

Shareholders with no voting rights should have a way to be represented by someone at the general assembly.

TBD.

Writing security test audits for contracts using the scribble framework from consensys.

Hi @sirhill , greetings for the new version of C-Layer , i have been experimenting with

This new framework allows the way to convert the sol files into flattened code , writing the strict assertions , for instance checking the code for an particular RBACWith multisig.sol

    public PublicMultiSig(_threshold, _duration, _participants, _weights)
  {
    /// if_succeeds {:msg : "checking-with-participant-roles" }  returns "_approvers == onlyApprovers ;
    updateManyParticipantsRoles(
      _participants,
      _suggesters,
      _approvers,
      _executers
    );
  }

PS: i might be wrong with the previous example , but just wanted to give an indication of the capablities .

so i wanted to ask will you be eager to talk about the possiblity of doing strict assertion checks .

Cheers

Voting contract tutorial

A new tutorial should be added covering the voting contract.

In particular, new voting features of the roadmap 1.2 should be included:

• execution of resolution Hash (issue #21)
• Voting rules per resolution Hash (issue #22)

It is to be seen if one tutorial is sufficient or two tutorial will be more appropriate.

GitHub Projects

I propose we use GitHub Projects for organizing work and assign tasks.

Accessing exceptions list of lock rule

It could be useful if the core token function could return the list of exceptions (lockExceptions address[]) allowed to bypass the lock rule, as set in defineLock, in addition to the start and end of the rule (lock uint256[2]).