# Timeline Aggregation Protocol (TAP)
| **tap_aggregator** | [](https://crates.io/crates/tap_aggregator) |
| **tap_core** | [](https://crates.io/crates/tap_core) |
| **tap_eip712_message** | [](https://crates.io/crates/tap_eip712_message)|
| **tap_graph** | [](https://crates.io/crates/tap_graph) |
| **tap_receipt** | [](https://crates.io/crates/tap_receipt) |
## Overview
The TAP (Timeline Aggregation Protocol) facilitates a series of payments from a
sender to a receiver (TAP Receipts), who aggregates these payments into a single
payment (a Receipt Aggregate Voucher, or RAV). This aggregate payment can then be
verified on-chain by a payment verifier, reducing the number of transactions and
simplifying the payment process.
## Documentation for Individual Components
- [tap_aggregator](tap_aggregator/README.md)
- [tap_core](tap_core/README.md) - links to this `README` for now.
## Key Components
- **Sender:** Initiates the payment.
- **Receiver:** Receives the payment.
- **Signers:** Multiple signers authorized by the sender to sign receipts.
- **State Channel:** A one-way channel opened by the sender with the receiver
for sending receipts.
- **Receipt:** A record of payment sent by the sender to the receiver.
- **ReceiptAggregateVoucher (RAV):** A signed message containing the aggregate
value of the receipts.
- **tap_aggregator:** A service managed by the sender that aggregates receipts
on the receiver's request into a signed RAV.
- **EscrowAccount:** An account created in the blockchain to hold funds for
the sender-receiver pair.
## Security Measures
- The protocol uses asymmetric cryptography (ECDSA secp256k1) to sign and
verify messages, ensuring the integrity of receipts and RAVs.
## Process
1. **Opening a State Channel:** A state channel is opened via a blockchain
contract, creating an EscrowAccount for the sender-receiver pair.
2. **Sending Receipts:** The sender sends receipts to the receiver through the
state channel.
3. **Storing Receipts:** The receiver stores the receipts and tracks the
aggregate payment.
4. **Creating a RAV Request:** A RAV request consists of a list of receipts and,
optionally, the previous RAV.
5. **Signing the RAV:** The receiver sends the RAV request to the tap_aggregator,
which signs it into a new RAV.
6. **Tracking Aggregate Value:** The receiver tracks the aggregate value and
new receipts since the last RAV.
7. **Requesting a New RAV:** The receiver sends new receipts and the last RAV
to the tap_aggregator for a new RAV.
8. **Closing the State Channel:** When the allocation period ends, the receiver
can send the last RAV to the blockchain and receive payment from the EscrowAccount.
## Performance Considerations
- The primary performance limitations are the time required to verify receipts
and network limitations for sending requests to the tap_aggregator.
## Use Cases
- The TAP protocol is suitable for systems that need unidirectional, parallel
micro-payments that are too expensive to redeem individually on-chain. By
aggregating operations off-chain and redeeming them in one transaction, costs
are drastically reduced.
## Compatibility
- The current implementation is for EVM-compatible blockchains, with most of the
system being off-chain.
## Contributing
Contributions are welcome! Please submit a pull request or open an issue to
discuss potential changes.
Also, make sure to follow the [Contributing Guide](https://github.com/semiotic-ai/timeline-aggregation-protocol/blob/main/CONTRIBUTING.md).