# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.xrpl-commons.org/core-dev-bootcamp/module03bis/homework3.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.