#Constellation #DAG Yes, I did take a look while researching other

layer 1 network.
Constellation DAG is a bit different to a "common" layer 1 network. Basically, it is a peer-to-peer network to send messages through it (finalized on a ledger).

A simple message can be a token transfer, the validators enforce that there are no double spends. But more complex messages are also possible.
However, they have not really a concept of decentralised smart contracts, but basically they use "state channels" as kind of smart contracts.
State channels basically are subnets or just one single node acting as an endpoint / client in their network. Meaning you can send messages to state channels and receive messages.
That's how they implemented a "dex" - as state channel which is running on centralised nodes (controlled by one party / team). You can swap via the network (by something like a swap message: I get 10 DAG for 0.1 WDAG), but e.g. providing liquidity isn't really decentralised.

Overall, it is more like a p2p network for decentralised applications where the messages are verified by consensus.
There are usecases sure, but I don't think they really compete with networks where smart contracts run really fully decentralised on ledger.

Also you can't easily compose different statechannels together in an atomic way in one single transaction like you do on Ethereum (e.g. creating a transaction which takes out a flashlona on Aave on one state channel and then swapping on Uniswap as dex on another state channel).

Therefore not really suitable for DeFi.

They also try to push the narrative that they are the "layer 0" for other networks. However, if you take a more critical perspective their "layer 0" network is kind of a layer 1 network where you can wrap other tokens like BTC or ETH -> this is what you can do on any other network too. Be it Ethereum, Cardano, Polkadot, Elrond or whatever. You only need a bridge.
Besides that, I first thought they have a cool bridge solution, but in the end their approach is simply a centralised bridge (like any other bridge out there at the moment - even RenVM is still centralised right now - though they are closest to their goal of a decentralised bridge).
They are proposing something like there are 3 nodes for each layer 1 network they support which are offering the bridge/wrapping via a state channel. E.g. 3 validators for Bitcoin (controlled by one party - also in control of all private keys for the BTC wallets).

You can checkout this video where the founder talks about the cross-chain bridge (in the beginning - very insightful to watch):
https://www.youtube.com/watch?v=0T7zcv_ieTc

Ah, and I am blocked in their TG group, because they didn't like that I said that their layer 0 is actually a layer 1 with a centralised bridge and wrapping tokens (which you can do anywhere).
Overall, their "layer 0" is more marketing than anything else.

Also on a sidenote while the tech founder is knowledgable the other members of the founding team are really lacking technical and just following their hero without questioning anything he says. This can be quite an execution risk.

Good morning everyone :) Here is a huge huge misunderstanding by the User and im not sure how that is actually possible after either reading the tokenomics v2 paper or watching some on the videos on mainnet 2.0 with Wyatt. Hypergraph State Channels are subnets that work similar like Polkadot's Parachain's —> they are completely interoperable with each other and can have different finality times depending on their need while still converging with the L0 consensus of the Hypergraph. The amount of Nodes is neither 1 or 3 for a State Channel —> the protocol team suggests to have at least 4 validation nodes running to utilize the decentralized/distributed security measures of the protocol. State Channels CAN be centralized, distributed OR decentralized —> this purely depends on the State Channel creators and their goal: For example the federal government (especially the DoD in our case) COULD decide to run a permissioned and distributed State Channel on our network because they do NOT want random people to validate their data.

Thanks @criptix ! So the example he gave about atomic swaps through a Bitcoin state channel bridge; Bitcoin still has to validate the transactions that occur on its side, even as a state channel, correct? It's not like somehow you can collude to update btc's ledger since it still relies on BTC's security to update the ledger on its side while on Constellation's side you are using the decentralized network of nodes (public or privately owned), that still are part of the global PRO consensus. The requirement of 4 nodes is basically a native requirement in order for a state channel's local consensus to successfully validate the data to be qualified for incorporation into the global consensus snapshot if I'm understanding it correctly. And the global snapshot still preserves the privacy of the local consensus of data that lets say DoD required. Also..the notion that there are wallets that are associated with the lattice state channel which are privately controlled is also false..correct? At least in respect to the state channels that facilitate cross chain atomic swaps or wrapped swaps (i.e. lattice)? The original commentor said state channel operators have access to the private keys to the wallets and can steal all the funds from the state channel that were swapped but that is not how the mechanics works at all from my understanding of lattice. Lastly, the claim that state channels are not capable of coordinating together on computation (atomic composability) because of the way the network orders transactions in a microservices architecture is also incorrect. State channels can directly work together to form consensus on a particular cross-state channel logic ("smart contract" or in our case "interstate contract") if desired since everything is normalized and ordered through hierarchy of data types which gets incorporated into global state snapshot asynchronously. I guess his conjecture is that cross-state channel logic would be asynchronous and not synchronous..unless there is maybe a common micro-service (layer 0 state channel) on the network that facilitates synchronous validation of cross-state channel logic? There are use cases for both types of ordering basically..if this then that sequences..as well as concurrent.

I find this an interesting topic. You had some questions in here @SethVi, are they answered somewhere? Cannot find a reply to your post and am curious if your reasoning has been confirmed.