Consul uses a consensus protocol to provide consistency of transactions, as defined by the Consistency, Availability, and Partition (CAP) tolerance theorem. The CAP theorem states that in a distributed system, we can achieve any two of the following qualities, but not all three:

• Consistency (C): Provides a single up-to-date copy of the data
• Availability (A): High availability of data for updates
• Partition (P): Tolerance to network partitions

Consul provides CP tolerance. Please refer to https://www.consul.io/intro/vs/serf.html for more information.

The basic steps involved in transaction processing using CAP are as follows:

1. The Remote Procedure Call (RPC) of the reading query type is returned by the leader. 
2. When a log entry (or event) is received by a leader, it sends the log entry to its followers (each server has one of three states: leader, follower, and candidate).
3. The followers send an OK message as an acknowledgment of a successful write.
4. The leader writes its entry and sends the commit state to followers while asking to change their state to commit.
5. When it receives OK messages from followers, the leader changes its state to commit.

Through consensus, the log entries are committed, and the Consistency part of the CAP theorem is achieved. Consensus is fault-tolerant as long as a quorum is available.

Consul follows the bootstrap for each data center to reduce network latency. A local data center server leader maintains separate peer sets to allow data to be partitioned by the data center. This way, every server leader of a data center is responsible for maintaining the state of its own data center. If a request is received for a remote data center, that request will be forwarded to the correct leader. This framework is designed for higher performance, low-latency transactions, and high availability of servers.