> 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/homework1.md).

# Homework 1: Trace a Transaction Through All Phases

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

***

### Objective

Use logging and debugging to trace a transaction through all four processing phases and document the state changes at each step.

***

### Prerequisites

* A compiled rippled build (debug mode recommended)
* A running rippled instance in standalone mode
* Familiarity with rippled logging configuration

***

### Tasks

#### Part 1: Enable Trace Logging

1. Configure your rippled to enable trace-level logging for the transaction subsystem:

```json
{
    "log_level": "trace",
    "log_channels": {
        "Transactor": "trace",
        "View": "trace"
    }
}
```

Or use the command-line:

```bash
./rippled --standalone --conf=rippled.cfg
```

Then in another terminal:

```bash
./rippled log_level Transactor trace
./rippled log_level View trace
```

***

#### Part 2: Create Test Accounts

1. Generate two test accounts using the `wallet_propose` RPC:

```bash
./rippled wallet_propose
```

2. Fund both accounts using the genesis account in standalone mode.
3. Record:
   * Account 1 address and sequence number
   * Account 2 address
   * Initial balances for both accounts

***

#### Part 3: Submit a CheckCreate Transaction

1. Create and sign a CheckCreate transaction:

```json
{
    "TransactionType": "CheckCreate",
    "Account": "<Account1>",
    "Destination": "<Account2>",
    "SendMax": "100000000",
    "Expiration": 800000000,
    "Fee": "12",
    "Sequence": <sequence>
}
```

2. Submit the transaction using the `submit` RPC.

***

#### Part 4: Analyze the Logs

Review the logs and identify entries for each phase:

**Preflight Phase:**

* What checks were logged?
* What was the result?

**Preclaim Phase:**

* What ledger entries were read?
* What checks were performed?
* What was the result?

**doApply Phase:**

* What ledger entries were created?
* What directories were modified?
* What owner counts changed?

**Finalization:**

* What was the final result code?
* What metadata was recorded?

***

#### Part 5: Document State Changes

Create a before/after comparison table:

| Object               | Field      | Before | After |
| -------------------- | ---------- | ------ | ----- |
| Account1 AccountRoot | Balance    | ?      | ?     |
| Account1 AccountRoot | OwnerCount | ?      | ?     |
| Account1 AccountRoot | Sequence   | ?      | ?     |
| Check                | (new)      | N/A    | ?     |
| Account1 OwnerDir    | Entries    | ?      | ?     |
| Account2 OwnerDir    | Entries    | ?      | ?     |

***

#### Part 6: Verify with RPC

Use RPC commands to verify your analysis:

```bash
# Check account state
./rippled account_info <Account1>

# Check account objects
./rippled account_objects <Account1>

# Get transaction details
./rippled tx <transaction_hash>
```

***

### Deliverables

1. **Log excerpts**: Key log entries from each phase (with annotations)
2. **State change table**: Completed before/after comparison
3. **Transaction metadata**: The `meta` field from the `tx` response
4. **Analysis**: Brief explanation of what happened in each phase

***

### Bonus Challenge

Repeat the exercise with a transaction that fails:

1. Create a CheckCreate to a non-existent account
2. Trace through the phases
3. Document where and why it failed
4. Compare the logs to the successful case

***

### Questions for Reflection

1. At what point does the sequence number get consumed?
2. At what point does the fee get deducted?
3. If doApply fails with `tecINSUFFICIENT_RESERVE`, what happens to the fee?
4. Why is the Check added to both account directories?