The Syntropy Data Layer comprises the four main Actors relying on the governance of the Syntropy blockchain powered by the $NOIA token. These actors include Publishers, Subscribers, Brokers, and Observers.
So how can attacks take place and what are the penalties?

To reduce the rate of bad behavior within the Syntropy network, penalization mechanisms should be implemented to punish cheaters. Here is how the penalty events that Syntropy sets up.

Double spending of subscribers

A Subscriber could be tempted to execute a double spending attack to reuse the same credit several times or at least twice, which is why it is called a double spending attack.

If such a situation is detected, the connection with this subscription instance should be terminated. Note that a subscriber as an on-chain entity may be represented by multiple instances, and clients that use its subscription, and may not control their behavior. Therefore, Syntropy evaluates any bad behavior and punishes it only if the double spending was caused by the subscriber.

Double customer spend

A client may not adhere to the protocol and misbehave by trying to execute a double-spend attack. This would involve using the same consumer token multiple times with the same or different broker nodes.

Since Broker nodes synchronize, they can easily detect this attack. There are several courses of action for Broker nodes.
It is also possible that the subscriber is guilty and providing the same consumption tokens to two customers. This should be provable and is covered by subscribers' double-spending.

Flooding of customer requests

A client can misbehave by sending multiple data delivery requests to multiple brokers at the same time.
Through synchronization within the Broker network, Broker nodes can detect this attack and generate proof of such behavior. Similar to Client double spending, Broker nodes can pre-block that Client and generate proof of fault, since the same consumption tokens will be used multiple times. This evidence may be relayed to the Subscriber to withdraw authorization to use the Service for that particular Customer.

Broker Submitting Invalid Proofs

A Broker may submit an invalid on-chain PoD. This may also mean that several observers may report it wrongly. This is a very undesirable event, which must be severely penalized. A significant portion of the attacking Broker's credit must be reduced.

Observer's Invalid Proof Attestation

If an Observer certifies an invalid PoD, 100% of their credit must be reduced. As in the previous case, the correct proof must be submitted on-chain by the challenger.

To learn more, please see the Syntropy Data Layer white paper.