@sentio/api 1.0.2-rc.21 → 1.0.2-rc.23

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (29) hide show
  1. package/dist/src/apis/DebugAndSimulationApi.d.ts +86 -114
  2. package/dist/src/apis/DebugAndSimulationApi.js +162 -190
  3. package/dist/src/apis/DebugAndSimulationApi.js.map +1 -1
  4. package/dist/src/apis/ForksApi.d.ts +12 -12
  5. package/dist/src/apis/ForksApi.js +30 -30
  6. package/dist/src/apis/ForksApi.js.map +1 -1
  7. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBodyChainSpec.d.ts +1 -1
  8. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBodyChainSpec.js +2 -2
  9. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBodyChainSpec.js.map +1 -1
  10. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody.d.ts +40 -0
  11. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody.js +48 -0
  12. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody.js.map +1 -0
  13. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBodyChainSpec.d.ts +32 -0
  14. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBodyChainSpec.js +42 -0
  15. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBodyChainSpec.js.map +1 -0
  16. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody.d.ts +40 -0
  17. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody.js +48 -0
  18. package/dist/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody.js.map +1 -0
  19. package/dist/src/models/index.d.ts +3 -0
  20. package/dist/src/models/index.js +3 -0
  21. package/dist/src/models/index.js.map +1 -1
  22. package/package.json +1 -1
  23. package/src/apis/DebugAndSimulationApi.ts +277 -299
  24. package/src/apis/ForksApi.ts +54 -54
  25. package/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBodyChainSpec.ts +3 -3
  26. package/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody.ts +89 -0
  27. package/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBodyChainSpec.ts +65 -0
  28. package/src/models/SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody.ts +89 -0
  29. package/src/models/index.ts +3 -0
package/dist/src/apis/DebugAndSimulationApi.d.ts CHANGED
@@ -10,48 +10,48 @@
10
10
  * Do not edit the class manually.
11
11
  */
12
12
  import * as runtime from '../runtime.js';
13
- import type { GoogleApiHttpBody, SolidityServiceGetSimulationBundleResponse, SolidityServiceGetSimulationResponse, SolidityServiceGetSimulationsResponse, SolidityServiceSimulateTransactionBundleResponse, SolidityServiceSimulateTransactionResponse, SolidityServiceSolidityAPIServiceSimulateTransactionBody, SolidityServiceSolidityAPIServiceSimulateTransactionBundleBody, TxindexEvmSearchTransactionsResponse } from '../models/index.js';
14
- export interface GetCallTraceRequest {
15
- projectOwner: string;
16
- projectSlug: string;
17
- chainSpecChainId: string;
18
- txIdTxHash: string;
13
+ import type { GoogleApiHttpBody, SolidityServiceGetSimulationBundleResponse, SolidityServiceGetSimulationResponse, SolidityServiceGetSimulationsResponse, SolidityServiceSimulateTransactionBundleResponse, SolidityServiceSimulateTransactionResponse, SolidityServiceSolidityAPIServiceSimulateTransactionBody, SolidityServiceSolidityAPIServiceSimulateTransactionBundleBody, SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody, SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody, TxindexEvmSearchTransactionsResponse } from '../models/index.js';
14
+ export interface GetCallTraceByBundleRequest {
15
+ owner: string;
16
+ slug: string;
17
+ chainId: string;
18
+ bundleId: string;
19
19
  chainSpecForkId?: string;
20
+ txIdTxHash?: string;
20
21
  txIdSimulationId?: string;
21
- txIdBundleId?: string;
22
22
  withInternalCalls?: boolean;
23
23
  disableOptimizer?: boolean;
24
24
  ignoreGasCost?: boolean;
25
25
  }
26
- export interface GetCallTrace2Request {
27
- projectOwner: string;
28
- projectSlug: string;
29
- chainSpecChainId: string;
30
- txIdSimulationId: string;
31
- chainSpecForkId?: string;
26
+ export interface GetCallTraceByForkBundleRequest {
27
+ owner: string;
28
+ slug: string;
29
+ forkId: string;
30
+ bundleId: string;
31
+ chainSpecChainId?: string;
32
32
  txIdTxHash?: string;
33
- txIdBundleId?: string;
33
+ txIdSimulationId?: string;
34
34
  withInternalCalls?: boolean;
35
35
  disableOptimizer?: boolean;
36
36
  ignoreGasCost?: boolean;
37
37
  }
38
- export interface GetCallTrace3Request {
39
- projectOwner: string;
40
- projectSlug: string;
41
- chainSpecChainId: string;
42
- txIdBundleId: string;
43
- chainSpecForkId?: string;
38
+ export interface GetCallTraceByForkSimulationRequest {
39
+ owner: string;
40
+ slug: string;
41
+ forkId: string;
42
+ simulationId: string;
43
+ chainSpecChainId?: string;
44
44
  txIdTxHash?: string;
45
- txIdSimulationId?: string;
45
+ txIdBundleId?: string;
46
46
  withInternalCalls?: boolean;
47
47
  disableOptimizer?: boolean;
48
48
  ignoreGasCost?: boolean;
49
49
  }
50
- export interface GetCallTrace4Request {
51
- projectOwner: string;
52
- projectSlug: string;
53
- chainSpecForkId: string;
54
- txIdTxHash: string;
50
+ export interface GetCallTraceByForkTransactionRequest {
51
+ owner: string;
52
+ slug: string;
53
+ forkId: string;
54
+ txHash: string;
55
55
  chainSpecChainId?: string;
56
56
  txIdSimulationId?: string;
57
57
  txIdBundleId?: string;
@@ -59,50 +59,50 @@ export interface GetCallTrace4Request {
59
59
  disableOptimizer?: boolean;
60
60
  ignoreGasCost?: boolean;
61
61
  }
62
- export interface GetCallTrace5Request {
63
- projectOwner: string;
64
- projectSlug: string;
65
- chainSpecForkId: string;
66
- txIdSimulationId: string;
67
- chainSpecChainId?: string;
62
+ export interface GetCallTraceBySimulationRequest {
63
+ owner: string;
64
+ slug: string;
65
+ chainId: string;
66
+ simulationId: string;
67
+ chainSpecForkId?: string;
68
68
  txIdTxHash?: string;
69
69
  txIdBundleId?: string;
70
70
  withInternalCalls?: boolean;
71
71
  disableOptimizer?: boolean;
72
72
  ignoreGasCost?: boolean;
73
73
  }
74
- export interface GetCallTrace6Request {
75
- projectOwner: string;
76
- projectSlug: string;
77
- chainSpecForkId: string;
78
- txIdBundleId: string;
79
- chainSpecChainId?: string;
80
- txIdTxHash?: string;
74
+ export interface GetCallTraceByTransactionRequest {
75
+ owner: string;
76
+ slug: string;
77
+ chainId: string;
78
+ txHash: string;
79
+ chainSpecForkId?: string;
81
80
  txIdSimulationId?: string;
81
+ txIdBundleId?: string;
82
82
  withInternalCalls?: boolean;
83
83
  disableOptimizer?: boolean;
84
84
  ignoreGasCost?: boolean;
85
85
  }
86
86
  export interface GetSimulationRequest {
87
- projectOwner: string;
88
- projectSlug: string;
87
+ owner: string;
88
+ slug: string;
89
89
  simulationId: string;
90
90
  }
91
91
  export interface GetSimulationBundleInProjectRequest {
92
- projectOwner: string;
93
- projectSlug: string;
92
+ owner: string;
93
+ slug: string;
94
94
  bundleId: string;
95
95
  }
96
96
  export interface GetSimulationsRequest {
97
- projectOwner: string;
98
- projectSlug: string;
97
+ owner: string;
98
+ slug: string;
99
99
  labelContains?: string;
100
100
  page?: number;
101
101
  pageSize?: number;
102
102
  }
103
103
  export interface SearchTransactionsRequest {
104
- projectOwner: string;
105
- projectSlug: string;
104
+ owner: string;
105
+ slug: string;
106
106
  chainId?: Array<string>;
107
107
  address?: Array<string>;
108
108
  includeDirect?: boolean;
@@ -119,93 +119,73 @@ export interface SearchTransactionsRequest {
119
119
  pageToken?: string;
120
120
  }
121
121
  export interface SimulateTransactionRequest {
122
- projectOwner: string;
123
- projectSlug: string;
124
- chainSpecChainId: string;
125
- body: SolidityServiceSolidityAPIServiceSimulateTransactionBody;
126
- }
127
- export interface SimulateTransaction2Request {
128
- projectOwner: string;
129
- projectSlug: string;
130
- chainSpecForkId: string;
122
+ owner: string;
123
+ slug: string;
124
+ chainId: string;
131
125
  body: SolidityServiceSolidityAPIServiceSimulateTransactionBody;
132
126
  }
133
127
  export interface SimulateTransactionBundleRequest {
134
- projectOwner: string;
135
- projectSlug: string;
136
- chainSpecChainId: string;
128
+ owner: string;
129
+ slug: string;
130
+ chainId: string;
137
131
  body: SolidityServiceSolidityAPIServiceSimulateTransactionBundleBody;
138
132
  }
139
- export interface SimulateTransactionBundle2Request {
140
- projectOwner: string;
141
- projectSlug: string;
142
- chainSpecForkId: string;
143
- body: SolidityServiceSolidityAPIServiceSimulateTransactionBundleBody;
133
+ export interface SimulateTransactionBundleByForkRequest {
134
+ owner: string;
135
+ slug: string;
136
+ forkId: string;
137
+ body: SolidityServiceSolidityAPIServiceSimulateTransactionBundleByForkBody;
138
+ }
139
+ export interface SimulateTransactionByForkRequest {
140
+ owner: string;
141
+ slug: string;
142
+ forkId: string;
143
+ body: SolidityServiceSolidityAPIServiceSimulateTransactionByForkBody;
144
144
  }
145
145
  /**
146
146
  *
147
147
  */
148
148
  export declare class DebugAndSimulationApi extends runtime.BaseAPI {
149
149
  /**
150
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
151
- * Get indexed call trace
152
150
  */
153
- getCallTraceRaw(requestParameters: GetCallTraceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
151
+ getCallTraceByBundleRaw(requestParameters: GetCallTraceByBundleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
154
152
  /**
155
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
156
- * Get indexed call trace
157
153
  */
158
- getCallTrace(requestParameters: GetCallTraceRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
154
+ getCallTraceByBundle(requestParameters: GetCallTraceByBundleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
159
155
  /**
160
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
161
- * Get indexed call trace
162
156
  */
163
- getCallTrace2Raw(requestParameters: GetCallTrace2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
157
+ getCallTraceByForkBundleRaw(requestParameters: GetCallTraceByForkBundleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
164
158
  /**
165
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
166
- * Get indexed call trace
167
159
  */
168
- getCallTrace2(requestParameters: GetCallTrace2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
160
+ getCallTraceByForkBundle(requestParameters: GetCallTraceByForkBundleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
169
161
  /**
170
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
171
- * Get indexed call trace
172
162
  */
173
- getCallTrace3Raw(requestParameters: GetCallTrace3Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
163
+ getCallTraceByForkSimulationRaw(requestParameters: GetCallTraceByForkSimulationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
174
164
  /**
175
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
176
- * Get indexed call trace
177
165
  */
178
- getCallTrace3(requestParameters: GetCallTrace3Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
166
+ getCallTraceByForkSimulation(requestParameters: GetCallTraceByForkSimulationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
179
167
  /**
180
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
181
- * Get indexed call trace
182
168
  */
183
- getCallTrace4Raw(requestParameters: GetCallTrace4Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
169
+ getCallTraceByForkTransactionRaw(requestParameters: GetCallTraceByForkTransactionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
184
170
  /**
185
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
186
- * Get indexed call trace
187
171
  */
188
- getCallTrace4(requestParameters: GetCallTrace4Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
172
+ getCallTraceByForkTransaction(requestParameters: GetCallTraceByForkTransactionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
189
173
  /**
190
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
191
- * Get indexed call trace
192
174
  */
193
- getCallTrace5Raw(requestParameters: GetCallTrace5Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
175
+ getCallTraceBySimulationRaw(requestParameters: GetCallTraceBySimulationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
194
176
  /**
195
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
196
- * Get indexed call trace
197
177
  */
198
- getCallTrace5(requestParameters: GetCallTrace5Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
178
+ getCallTraceBySimulation(requestParameters: GetCallTraceBySimulationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
199
179
  /**
200
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
180
+ * API to get Sentio call trace. It takes `txId.txHash` and `chainSpec.chainId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
201
181
  * Get indexed call trace
202
182
  */
203
- getCallTrace6Raw(requestParameters: GetCallTrace6Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
183
+ getCallTraceByTransactionRaw(requestParameters: GetCallTraceByTransactionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GoogleApiHttpBody>>;
204
184
  /**
205
- * API to get Sentio call trace. It takes `txId.txHash` and `networkId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
185
+ * API to get Sentio call trace. It takes `txId.txHash` and `chainSpec.chainId` arguments, where the first is transaction hash, and the second is the numeric ethereum chain ID. The results looks very similar to the normal [Ethereum call trace](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png). But we have an additional `startIndex` and `startIndex` on each trace entry even for the LOG, representing the execution order in the trace. This allows you to build chart that marks the order of fund flow. ![screenshot](https://raw.githubusercontent.com/sentioxyz/docs/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png)
206
186
  * Get indexed call trace
207
187
  */
208
- getCallTrace6(requestParameters: GetCallTrace6Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
188
+ getCallTraceByTransaction(requestParameters: GetCallTraceByTransactionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GoogleApiHttpBody>;
209
189
  /**
210
190
  * Get a simulation by id
211
191
  */
@@ -248,16 +228,6 @@ export declare class DebugAndSimulationApi extends runtime.BaseAPI {
248
228
  * Single simulation
249
229
  */
250
230
  simulateTransaction(requestParameters: SimulateTransactionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionResponse>;
251
- /**
252
- * Create a new transaction simulation. The simulation body should be included in the request body. Your simulations will be saved, and a unique ID for each simulation is included in the response. It will be useful for fetching simulation details.
253
- * Single simulation
254
- */
255
- simulateTransaction2Raw(requestParameters: SimulateTransaction2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SolidityServiceSimulateTransactionResponse>>;
256
- /**
257
- * Create a new transaction simulation. The simulation body should be included in the request body. Your simulations will be saved, and a unique ID for each simulation is included in the response. It will be useful for fetching simulation details.
258
- * Single simulation
259
- */
260
- simulateTransaction2(requestParameters: SimulateTransaction2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionResponse>;
261
231
  /**
262
232
  * You could also create bundle simulations so that one transaction could be executed one after another. For `blockNumber` `transactionIndex` `networkId` `stateOverrides` and `blockOverrides` fields, only the first simulation takes effect.
263
233
  * Bundle simulation
@@ -269,13 +239,15 @@ export declare class DebugAndSimulationApi extends runtime.BaseAPI {
269
239
  */
270
240
  simulateTransactionBundle(requestParameters: SimulateTransactionBundleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionBundleResponse>;
271
241
  /**
272
- * You could also create bundle simulations so that one transaction could be executed one after another. For `blockNumber` `transactionIndex` `networkId` `stateOverrides` and `blockOverrides` fields, only the first simulation takes effect.
273
- * Bundle simulation
274
242
  */
275
- simulateTransactionBundle2Raw(requestParameters: SimulateTransactionBundle2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SolidityServiceSimulateTransactionBundleResponse>>;
243
+ simulateTransactionBundleByForkRaw(requestParameters: SimulateTransactionBundleByForkRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SolidityServiceSimulateTransactionBundleResponse>>;
244
+ /**
245
+ */
246
+ simulateTransactionBundleByFork(requestParameters: SimulateTransactionBundleByForkRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionBundleResponse>;
247
+ /**
248
+ */
249
+ simulateTransactionByForkRaw(requestParameters: SimulateTransactionByForkRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SolidityServiceSimulateTransactionResponse>>;
276
250
  /**
277
- * You could also create bundle simulations so that one transaction could be executed one after another. For `blockNumber` `transactionIndex` `networkId` `stateOverrides` and `blockOverrides` fields, only the first simulation takes effect.
278
- * Bundle simulation
279
251
  */
280
- simulateTransactionBundle2(requestParameters: SimulateTransactionBundle2Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionBundleResponse>;
252
+ simulateTransactionByFork(requestParameters: SimulateTransactionByForkRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SolidityServiceSimulateTransactionResponse>;
281
253
  }