Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: release v4.5.6 #512

Merged
merged 5 commits into from
Jun 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,24 @@
# @biconomy/account

## 4.4.6

### Patch Changes

- Move SessionStorageClient to its own package (https://www.npmjs.com/package/@biconomy/session-file-storage)

## 4.4.5

### Patch Changes

- modifications for token payment + session support

- Added "toSupportedSigner" helper for privateKey -> supportedSigner translation
- Added "toSessionParams" helper for privateKey -> session params translation
- Tweaked getBatchSessionTxParams to return last n leaves by default, so users do not always have to find the correct session leaf
- Tweaked getSingleSessionTxParams to return last n leaves by default, so users do not always have to find the correct session leaf
- Tweaked createABISessionDatum to allow devs to manually input the functionSelector
- Exported BICONOMY_TOKEN_PAYMASTER, useful for manually building approvals

## 4.4.4

### Patch Changes
Expand Down
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,7 @@ For a comprehensive understanding of our project and to contribute effectively,
- [send some eth with sponsorship](examples/SEND_SOME_ETH_WITH_SPONSORSHIP.md)
- [send a multi tx and pay gas with an erc20 token](examples/SEND_A_MULTI_TX_AND_PAY_GAS_WITH_TOKEN.md)
- [create and use a session](examples/CREATE_AND_USE_A_SESSION.md)
- [create and use a batch session](examples/CREATE_AND_USE_A_BATCH_SESSION.md)

## License

Expand Down
Binary file modified bun.lockb
Binary file not shown.
26 changes: 24 additions & 2 deletions examples/CREATE_AND_USE_A_SESSION.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,10 +32,32 @@ const { sessionKeyAddress, sessionStorageClient } = await createSessionKeyEOA(
chain
);

// The rules that govern the method from the whitelisted contract
/**
* Rule
*
* https://docs.biconomy.io/Modules/abiSessionValidationModule#rules
*
* Rules define permissions for the args of an allowed method. With rules, you can precisely define what should be the args of the transaction that is allowed for a given Session. Every Rule works with a single static arg or a 32-byte chunk of the dynamic arg.
* Since the ABI Encoding translates every static param into a 32-bytes word, even the shorter ones (like address or uint8), every Rule defines a desired relation (Condition) between n-th 32bytes word of the calldata and a reference Value (that is obviously a 32-bytes word as well).
* So, when dApp is creating a _sessionKeyData to enable a session, it should convert every shorter static arg to a 32bytes word to match how it will be actually ABI encoded in the userOp.callData.
* For the dynamic args, like bytes, every 32-bytes word of the calldata such as offset of the bytes arg, length of the bytes arg, and n-th 32-bytes word of the bytes arg can be controlled by a dedicated Rule.
*/
const rules: Rule = [
{
/** The index of the param from the selected contract function upon which the condition will be applied */
/**
*
* offset
*
* https://docs.biconomy.io/Modules/abiSessionValidationModule#rules
*
* The offset in the ABI SVM contract helps locate the relevant data within the function call data, it serves as a reference point from which to start reading or extracting specific information required for validation. When processing function call data, particularly in low-level languages like Solidity assembly, it's necessary to locate where specific parameters or arguments are stored. The offset is used to calculate the starting position within the calldata where the desired data resides. Suppose we have a function call with multiple arguments passed as calldata. Each argument occupies a certain number of bytes, and the offset helps determine where each argument begins within the calldata.
* Using the offset to Extract Data: In the contract, the offset is used to calculate the position within the calldata where specific parameters or arguments are located. Since every arg is a 32-bytes word, offsets are always multiplier of 32 (or of 0x20 in hex).
* Let's see how the offset is applied to extract the to and value arguments of a transfer(address to, uint256 value) method:
* - Extracting to Argument: The to argument is the first parameter of the transfer function, representing the recipient address. Every calldata starts with the 4-bytes method selector. However, the ABI SVM is adding the selector length itself, so for the first argument the offset will always be 0 (0x00);
* - Extracting value Argument: The value argument is the second parameter of the transfer function, representing the amount of tokens to be transferred. To extract this argument, the offset for the value parameter would be calculated based on its position in the function calldata. Despite to is a 20-bytes address, in the solidity abi encoding it is always appended with zeroes to a 32-bytes word. So the offset for the second 32-bytes argument (which isthe value in our case) will be 32 (or 0x20 in hex).
*
* If you need to deal with dynamic-length arguments, such as bytes, please refer to this document https://docs.soliditylang.org/en/v0.8.24/abi-spec.html#function-selector-and-argument-encoding to learn more about how dynamic arguments are represented in the calldata and which offsets should be used to access them.
*/
offset: 0,
/**
* Conditions:
Expand Down
3 changes: 2 additions & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
"sideEffects": false,
"name": "@biconomy/account",
"author": "Biconomy",
"version": "4.4.4",
"version": "4.4.6",
"description": "SDK for Biconomy integration with support for account abstraction, smart accounts, ERC-4337.",
"keywords": [
"erc-7579",
Expand Down Expand Up @@ -58,6 +58,7 @@
"build": "bun run clean && bun run build:cjs && bun run build:esm && bun run build:types",
"clean": "rimraf ./dist/_esm ./dist/_cjs ./dist/_types ./dist/tsconfig",
"test": "vitest dev -c ./tests/vitest.config.ts",
"playground": "bun run test -t=Playground --watch",
"test:readOnly": "bun run test read",
"test:watch": "bun run test --watch",
"test:watch:readOnly": "bun run test:readOnly --watch",
Expand Down
3 changes: 3 additions & 0 deletions src/account/BiconomySmartAccountV2.ts
Original file line number Diff line number Diff line change
Expand Up @@ -211,6 +211,7 @@ export class BiconomySmartAccountV2 extends BaseSmartContractAccount {
this.scanForUpgradedAccountsFromV1 =
biconomySmartAccountConfig.scanForUpgradedAccountsFromV1 ?? false
this.maxIndexForScan = biconomySmartAccountConfig.maxIndexForScan ?? 10
this.getAccountAddress()
}

/**
Expand Down Expand Up @@ -1227,10 +1228,12 @@ export class BiconomySmartAccountV2 extends BaseSmartContractAccount {
// biome-ignore lint/performance/noDelete: <explanation>
delete userOp.signature
const userOperation = await this.signUserOp(userOp, params)

const bundlerResponse = await this.sendSignedUserOp(
userOperation,
params?.simulationType
)

return bundlerResponse
}

Expand Down
3 changes: 3 additions & 0 deletions src/account/utils/Constants.ts
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,9 @@ export const BICONOMY_FACTORY_ADDRESSES: BiconomyFactories = {
"0x000000a56Aaca3e9a4C479ea6b6CD0DbcB6634F5": "V2_0_0"
}

export const BICONOMY_TOKEN_PAYMASTER =
"0x00000f7365cA6C59A2C93719ad53d567ed49c14C"

// will always be latest implementation address
export const DEFAULT_BICONOMY_IMPLEMENTATION_ADDRESS =
"0x0000002512019Dafb59528B82CB92D3c5D2423aC"
Expand Down
2 changes: 1 addition & 1 deletion src/bundler/utils/Constants.ts
Original file line number Diff line number Diff line change
Expand Up @@ -29,4 +29,4 @@ export const UserOpWaitForTxHashMaxDurationIntervals: {
export const DEFAULT_ENTRYPOINT_ADDRESS =
"0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789"

export const SDK_VERSION = "4.2.0"
export const SDK_VERSION = "4.4.5"
6 changes: 0 additions & 6 deletions src/modules/SessionKeyManagerModule.ts
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,6 @@ import type {
SessionSearchParam,
SessionStatus
} from "./interfaces/ISessionStorage.js"
import { SessionFileStorage } from "./session-storage/SessionFileStorage.js"
import { SessionLocalStorage } from "./session-storage/SessionLocalStorage.js"
import { SessionMemoryStorage } from "./session-storage/SessionMemoryStorage.js"
import {
Expand Down Expand Up @@ -93,11 +92,6 @@ export class SessionKeyManagerModule extends BaseValidationModule {
moduleConfig.smartAccountAddress
)
break
case StorageType.FILE_STORAGE:
instance.sessionStorageClient = new SessionFileStorage(
moduleConfig.smartAccountAddress
)
break
case StorageType.LOCAL_STORAGE:
instance.sessionStorageClient = new SessionLocalStorage(
moduleConfig.smartAccountAddress
Expand Down
Loading
Loading