layer-3 / clearsync Goto Github PK

• missing config example in the README or directly in the pkg
• DEX price feeds should have default RPC URLs, for example default chain for SyncSwap is Linea and there is an official RPC for it, if it's Uniswap with ETH it should Infura (if you don't have, I can provide URL)
• missing proper error handling of the empty env for the RPC URLs
  websocket URL must start with ws:// or wss:// (got '') - example

Generating a session key in the Ethereum ecosystem typically involves creating a new Ethereum account (which inherently means generating a new public-private key pair) that is authorized to act on behalf of the main account under specific conditions. This new account acts as the session key. Ethereum itself doesn't have a built-in "session key" type or interface per se, but you can implement this concept through smart contract logic.

Here's a simplified approach to generating and using a session key:

1. Generate a New Ethereum Account:

• This can be done using standard Ethereum wallet software or libraries like ethers.js or web3.js. This new account will be your session key.

2. Set Permissions in Your Main Account's Smart Contract:

• Modify the smart contract controlling your main account to recognize and accept transactions from this new session key under specific conditions. This could be implemented through a function that checks if the sender is the authorized session key and validates the transaction based on predefined rules (like transaction limits, function access, time bounds, etc.).

Example Smart Contract:

Here’s a basic example using Solidity:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SessionKeyManager {
    address public mainAccount;
    address public sessionKey;
    uint256 public sessionKeyExpiration;

    constructor() {
        mainAccount = msg.sender;
    }

    // Set a new session key with an expiration time
    function setSessionKey(address _sessionKey, uint256 duration) external {
        require(msg.sender == mainAccount, "Only main account can set session key");
        sessionKey = _sessionKey;
        sessionKeyExpiration = block.timestamp + duration;
    }

    // Function that checks if the caller is the valid session key
    modifier onlySessionKey() {
        require(msg.sender == sessionKey, "Caller is not the session key");
        require(block.timestamp <= sessionKeyExpiration, "Session key expired");
        _;
    }

    // Example of a restricted function
    function doSomethingRestricted() external onlySessionKey {
        // Restricted logic here
    }

    // Function to clear the session key
    function clearSessionKey() external {
        require(msg.sender == mainAccount || msg.sender == sessionKey, "Unauthorized");
        sessionKey = address(0);
        sessionKeyExpiration = 0;
    }
}

In this contract:

• The mainAccount can set a sessionKey with a specific expiration time.
• The doSomethingRestricted function can only be called by the sessionKey and only if it hasn't expired.
• The sessionKey can be cleared by either the mainAccount or the sessionKey itself.

Generating the Session Key with Web3.js:

Using Web3.js, you can generate a new account like this:

const Web3 = require('web3');
const web3 = new Web3(Web3.givenProvider || 'ws://localhost:8545');

const sessionKeyAccount = web3.eth.accounts.create();
console.log("Session Key Address:", sessionKeyAccount.address);
console.log("Session Key Private Key:", sessionKeyAccount.privateKey);

Important Considerations:

• Security: Make sure that the session key is securely stored and transmitted. If the session key is compromised, the attacker can perform any action that the session key is authorized to do.
• Audit and Testing: Smart contracts should be thoroughly tested and audited, especially those handling permissions and financial transactions.
• Gas Fees: Transactions made by the session key will incur gas fees, which must be paid by the account executing the transaction (the session key account in this case).
• Revocation: Ensure that your contract logic allows the main account to revoke or change the session key.

This implementation is quite basic. Depending on your specific requirements, you might need a more sophisticated system with additional checks, balances, and features.

1. I assume that only NeoDAX is allowed to configure zone, that will work with Terminal. What about zones from NeoDAX to NeoDAX, who's zone will be selected?
2. I do not think that we should allow to configure the margin zone, at least at the start. it's a config we want to avoid. So we can define it now to keep us safe and update later on.
3. If configuring is accepted, then it has to be one of the connections to the peer parameter, with an issue in point 1 of this list.
4. The zone should not be possible to change during the active trade period as it is abusive behavior, so notification about the change of the zone is not essential.
5. Both Yellow and Red zones mentioned that trades are not allowed, but I think it is about orders. How we will decline order matching into a trade if there are open orders already? I suggest that the yellow zone does not allow to creation of new orders and the red zone cancels all before settlement, but we need to give it more thought for sure.
6. The yellow zone allows the user to select what to settle, but the settle outcome should result in a green zone.

ToDo:
Read the docs, remove outdated parts and add the new vision

It was tested via testnet.yellow.org, but will there be a different test network in the future?

• Configure entire directory for linea-mainnet here
  • peers.json should contain domains of clearports that we are going to deploy on this network, ports depend on the infrastructure; addresses should be got from private keys generated for each node; names can be chosen freely
  • blockchain.json should include correct addresses of all deployed contracts, blockchainRPC should point to WS endpoint of network node
  • assets.json should include all assets that can be accepted by a clearport and listed in the yellow wallet
  • markets.json all markets supported by Kayen (currently only USD quotes are supported)

Considerations

Difficulty of one node deployment depend on the infrastructure and whether it has already PostgreSQL and InfluxDB instances that can be used.

A participant may not have assets on hand to settle a trade, therefore a more elaborate red zone reaction should be thought of.

By @dpatsora about YIP 0006 - Margin Zones.

fix FIXME and do TODO

Both Yellow and Red zones mentioned that trades are not allowed, but I think it is about orders.

By @pkucherenk0 in #124 .

Problem to solve: It was agreed that the Alpa will be released on the Canary (network placeholder) main-net network. This should make Alpha more influential for testers, the team, and the community. Allowing us to transit to the main-net more easily, and find the issues and abuses prior to the public release. This will create adoption metrics for VC

Acceptance Criteria:

1. Deploy bridge DUCKIES (as a safety token) to (network placeholder) L1+L2
2. Index Price feed should support the market list on the (network placeholder)
3. ClearPort should be able to operate on (network placeholder)
4. ClearSync SC should be deployed and operation on (network placeholder) L2
5. User should connect his wallet on the (network placeholder)