> For the complete documentation index, see [llms.txt](https://docs.xrpl-commons.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xrpl-commons.org/core-dev-bootcamp/module03bis/homework3.md).

# Homework 3: Analyze TER Code Paths

[← Back to Transactors: Understanding the Lifecycle of a Transaction](/core-dev-bootcamp/module03bis.md)

***

### Objective

Map out the conditions that lead to different TER codes for the CheckCreate transactor and create a decision tree.

***

### Background

Understanding which conditions lead to which result codes is essential for:

* Building applications that handle errors correctly
* Debugging transaction failures
* Implementing new transactors with appropriate error handling

***

### Tasks

#### Part 1: Code Analysis

Review `CreateCheck.cpp` and identify every return statement with its result code.

Create a table:

| Phase     | Code            | Condition                                         | Description    |
| --------- | --------------- | ------------------------------------------------- | -------------- |
| preflight | `temREDUNDANT`  | `Account == Destination`                          | Self-send      |
| preflight | `temBAD_AMOUNT` | `!isLegalNet(sendMax) \|\| sendMax.signum() <= 0` | Invalid amount |
| ...       | ...             | ...                                               | ...            |

***

#### Part 2: Create a Decision Tree

Draw a flowchart showing how each result code can be reached:

```
CheckCreate Transaction
        │
        ▼
┌───────────────────┐
│ Account == Dest?  │
├───────────────────┤
│ YES → temREDUNDANT│
│ NO  → ▼           │
└───────────────────┘
        │
        ▼
┌───────────────────┐
│ Amount valid?     │
├───────────────────┤
│ NO  → temBAD_AMOUNT│
│ YES → ▼           │
└───────────────────┘
        │
        ... continue ...
```

You can use:

* ASCII art (like above)
* A drawing tool (Mermaid, draw\.io, etc.)
* Hand-drawn diagram (photo)

***

#### Part 3: Categorize by Phase

Group the result codes by phase:

**Preflight (returns NotTEC):**

* `temREDUNDANT`
* `temBAD_AMOUNT`
* `temBAD_CURRENCY`
* `temBAD_EXPIRATION`

**Preclaim (can return TEC):**

* `tecNO_DST`
* `tecNO_PERMISSION`
* `tecDST_TAG_NEEDED`
* `tecFROZEN`
* `tecEXPIRED`

**doApply (can return TEC):**

* `tefINTERNAL`
* `tecINSUFFICIENT_RESERVE`
* `tecDIR_FULL`
* `tesSUCCESS`

***

#### Part 4: Identify Implicit Checks

Some checks are performed by the base `Transactor` class, not by `CreateCheck` itself:

1. **Fee validation**: Where is this checked?
2. **Sequence validation**: Where is this checked?
3. **Signature validation**: Where is this checked?

Add these to your decision tree.

***

#### Part 5: Create Test Scenarios

For each possible result code, describe a test scenario that would trigger it:

| Result Code     | Test Scenario                                         |
| --------------- | ----------------------------------------------------- |
| `temREDUNDANT`  | Create check with same source and destination account |
| `temBAD_AMOUNT` | Create check with SendMax = 0                         |
| `tecNO_DST`     | Create check to non-existent account                  |
| ...             | ...                                                   |

***

### Deliverables

1. **Complete table** of all return statements and conditions
2. **Decision tree diagram** showing all code paths
3. **Phase categorization** with explanations
4. **Test scenario list** for each result code

***

### Analysis Questions

Answer the following:

1. **Why can't preflight return `tec` codes?**
   * Explain the security implications
2. **What's the difference between `tecNO_DST` and `temDST_NEEDED`?**
   * When would each be used?
3. **If a transaction fails with `tecFROZEN`, what exactly was frozen?**
   * Identify all the freeze checks
4. **Can a CheckCreate ever fail in doApply with a result other than `tesSUCCESS`, `tefINTERNAL`, `tecINSUFFICIENT_RESERVE`, or `tecDIR_FULL`?**
   * Explain why or why not
5. **What result code would you expect for each scenario:**
   * Check with Expiration = 0
   * Check with SendMax = -100 XRP
   * Check to an AMM pool account
   * Check with destination tag when lsfRequireDestTag is set

***

### Bonus Challenge

Create a similar analysis for `CashCheck` and compare the result code patterns. What codes are unique to each transaction type?

***

### Resources

* `src/xrpld/app/tx/detail/CreateCheck.cpp` - CheckCreate implementation
* `include/xrpl/protocol/TER.h` - TER code definitions
* `src/xrpld/app/tx/detail/Transactor.cpp` - Base class checks