Conversation
Ryang-21
commented
Nov 5, 2025
- Added examples for Rpc Server methods
- Added examples for AssembledTransaction usage
|
Size Change: -91.2 kB (-0.22%) Total Size: 42.2 MB
|
| args: [ | ||
| nativeToScVal(invoker.publicKey(), { type: 'address' }), // from | ||
| nativeToScVal(alice.publicKey(), { type: 'address' }), // to | ||
| nativeToScVal('100', { type: 'i128' }), // amount | ||
| ], |
There was a problem hiding this comment.
here's a nicer way I'd like to encourage people to do things
| args: [ | |
| nativeToScVal(invoker.publicKey(), { type: 'address' }), // from | |
| nativeToScVal(alice.publicKey(), { type: 'address' }), // to | |
| nativeToScVal('100', { type: 'i128' }), // amount | |
| ], | |
| args: nativeToScVal([ | |
| invoker.publicKey(), | |
| alice.publicKey(), | |
| '100' | |
| ], { | |
| type: [ 'address', 'address', 'i128' ] | |
| }).vec(), |
There was a problem hiding this comment.
I wasn't aware you could use it like that. The one problem with .vec() is that its return types use null instead of undefined which args does not take
There was a problem hiding this comment.
Why not spec.funcArgsToScVals as in the old docs?
There was a problem hiding this comment.
I'm not sure what you mean by
its return types use null instead of undefined which args does not take
.vec() returns ScVal[]? which is compatible with build's any[] if you ! it
Why not spec.funcArgsToScVals as in the old docs?
There's no spec in this case from what I can tell
There was a problem hiding this comment.
I chose to not use Spec functionality as its not essential for AssembledTransaction to work. That might be a wrong choice though. My editor has the return type of .vec() as ScVal[] | null and the AssembledTransaction interface expects undefined
|
|
||
| Use `buildWithOp()` when you need to create transactions with operations other than `invokeHostFunction`, such as deploying contracts or extending TTL. | ||
|
|
||
| The following `Operations` are allowed |
There was a problem hiding this comment.
It's worth noting that some of these aren't "real" operations in the list-of-operations sense and rather just convenience methods
| const allSigners = tx.needsNonInvokerSigningBy({ | ||
| includeAlreadySigned: true | ||
| }); | ||
| ``` |
There was a problem hiding this comment.
can we include the actual signing here as well?
IIRC you can't just sign the transaction with all parties as normal (e.g. Transaction.sign(secret)), as Soroban expects only the authorization entry itself to be signed
|
|
||
| --- | ||
|
|
||
| ## Multi-Auth Workflows |
There was a problem hiding this comment.
Is this section different enough from the one starting on line 175 to be worth including? Seems possibly like duplicate content.