> For the complete documentation index, see [llms.txt](https://help.keyring.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.keyring.app/keyring-one/what-is-keyring-one.md).
# What Is KEYRING ONE
KEYRING ONE is a non-custodial, on-chain financial management and automation platform for businesses, organizations, and Web3 teams. It also provides DeFi features for individual wallet users.
The platform brings shared asset management, recurring revenue distribution, lending, and trading into one interface. Organizations can establish approval rules for shared funds and automate recurring operations, while individual users can access supported lending protocols and place orders through Uniswap v4.
Multisig Account features use shared-account assets and follow their applicable authorization rules.
> **Note:** DeFi features, such as **Trading (Limit Orders)** and **Lending**, operate through the user’s connected **single wallet**, using assets held in that wallet. These features do not use a Multisig Account or its shared assets.
#### Transparent and Non-Custodial Infrastructure
KEYRING ONE does not take custody of user or organizational assets. Assets are handled by the relevant smart contracts and authorized wallets or signers according to the rules of each feature.
Executed contract transactions and asset movements are recorded on-chain and can be independently examined. The Multisig Account audit and the published LimitOrderHook source provide separate references for reviewing these parts of the platform.
## Audit and Source Code
#### 1. Multisig Account Audit — BlockSec
[BlockSec Security Audit Report for KEYRING’s multisig-wallet-contracts](https://blocksec.com/audit-report/audit-report-keyring-s-multisig-wallet-contracts-1784184202)
{% embed url="" %}
This report documents BlockSec’s independent review of the specified KEYRING Multisig Account contracts. It describes the audit scope, findings, and reviewed code versions.
#### 2. Verified LimitOrderHook Source
[LimitOrderHook Contract Source on BaseScan](https://basescan.org/address/0xEEee3DA335342996Ab288fBcF70fBe5F9ED81040#code)
{% embed url="" %}
This is the published source for the LimitOrderHook deployed on Base at `0xEEee3DA335342996Ab288fBcF70fBe5F9ED81040`, including its dependencies. It is the source used for the code explanations below.
#### 3. Hook Submission — Uniswap Hooklist
[Smart Limit Order Hook Submission](https://github.com/Uniswap/hooklist/issues/10506)
{% embed url="" %}
This submission describes the Hook, identifies Base as its deployment network, and provides its contract address. It is a descriptive submission, rather than an audit report or a Uniswap endorsement.
## Multisig Account Audit
The KEYRING ONE Multisig Account smart contracts were independently audited by [BlockSec](https://blocksec.com/), a blockchain security firm.
BlockSec’s published materials report 1,000+ clients and more than $50 billion in digital assets secured. Its documented audit experience includes PancakeSwap, OKX Smart Wallet, and Rabby Wallet.
#### What Was Audited
BlockSec reviewed the core smart contract logic used by KEYRING ONE Multisig Accounts, including:
* Multisig Account creation.
* Signer and approval-threshold configuration.
* Signature verification.
* Withdrawal authorization.
* Replay protection for withdrawal requests.
* Smart contract handling of native tokens and supported blockchain assets.
The review combined automated vulnerability scanning, manual code verification, and analysis of the contract’s business logic.
The audit applies to the code versions and scope specified in the report. It should not be interpreted as an audit of every KEYRING ONE feature or of the LimitOrderHook discussed below.
> **The audit gives users an independent assessment of the reviewed multisig implementation, including the logic that checks signer approvals and authorizes withdrawals from shared accounts.**
## The Code Behind Limit Orders
KEYRING ONE’s Limit Order feature runs through the custom LimitOrderHook on Uniswap v4. Its published code makes the order mechanism available for independent review.
The Hook is based on OpenZeppelin Uniswap Hooks, an open-source library developed by OpenZeppelin, an established blockchain security company known for its widely used smart contract libraries and security services. KEYRING ONE’s implementation builds on that foundation, with modifications documented in the source.
The following analysis covers the verified LimitOrderHook deployment on Base and its included dependencies. It does not analyze the implementation of the platform’s other features, including scheduled Automatic Limit Orders.
Some comments and surrounding code are omitted from the excerpts, and indentation is adjusted for readability. The original code statements are unchanged.
#### What Is a Uniswap v4 Hook?
A Uniswap v4 Hook is a smart contract that adds custom logic to a liquidity pool. Uniswap v4 calls the Hook at the pool-operation stages enabled by its configuration.
For KEYRING ONE, the LimitOrderHook implements the on-chain mechanism for Limit Orders. It records contributions, places order assets into narrow liquidity ranges, processes eligible fills, and handles cancellation and withdrawal accounting.
**When Uniswap v4 Calls the Hook**
The Hook declares its enabled callbacks through `getHookPermissions()`:
```solidity
function getHookPermissions() public pure virtual override returns (Hooks.Permissions memory permissions) {
return Hooks.Permissions({
beforeInitialize: false,
afterInitialize: true,
beforeAddLiquidity: false,
beforeRemoveLiquidity: false,
afterAddLiquidity: false,
afterRemoveLiquidity: false,
beforeSwap: false,
afterSwap: true,
beforeDonate: false,
afterDonate: false,
beforeSwapReturnDelta: false,
afterSwapReturnDelta: false,
afterAddLiquidityReturnDelta: false,
afterRemoveLiquidityReturnDelta: false
});
}
```
This implementation enables two callbacks:
* **`afterInitialize`** records the pool’s initial lower tick and rejects native-currency pools.
* **`afterSwap`** checks the price ranges crossed by a swap and processes eligible orders.
The entries set to `false` are callbacks this Hook does not enable.
> **The Hook’s configuration enables its checks after pool swaps. Together with the fill-processing logic, this allows eligible orders to be processed through pool activity without a separate wallet approval for the fill. Users still need to submit a withdrawal transaction to receive the proceeds.**
**How the Hook Processes Orders After a Swap**
Inside `_afterSwap()`, the Hook identifies crossed tick ranges, updates its reference, and processes the relevant order direction:
```solidity
(int24 tickLower, int24 lower, int24 upper) = _getCrossedTicks(key.toId(), key.tickSpacing);
if (lower > upper) return (this.afterSwap.selector, 0);
_tickLowerLasts[key.toId()] = tickLower;
bool zeroForOne = !params.zeroForOne;
for (; lower <= upper; lower += key.tickSpacing) {
_fillOrder(key, lower, zeroForOne);
}
return (this.afterSwap.selector, 0);
```
Ticks represent price boundaries in the pool. `_getCrossedTicks()` determines which ranges need to be checked, and `_fillOrder()` processes active orders at those ranges.
This callback runs after the pool’s swap logic, within the same transaction. The user does not need to sign a separate transaction for the Hook to process an eligible fill triggered by that swap.
Execution depends on price movement in the relevant pool. The Hook does not use an external exchange price feed or a scheduled price-checking process.
> **An order progresses through swaps in its own pool. A price shown on another exchange does not by itself fill the order, so users need to check completion against the actual on-chain order status.**
**How the Components Work Together**
* **KEYRING ONE** provides the interface for creating and managing orders.
* **LimitOrderHook** implements order accounting, fill processing, cancellation, withdrawal, and LP fee routing.
* **Uniswap v4** provides the pool infrastructure used by those operations.
The source header identifies the Hook as a modified version of OpenZeppelin Uniswap Hooks v1.2.0. It documents changes to principal accounting, fee routing, withdrawal accounting, and native-currency support.
> **Users access KEYRING ONE to create and manage orders, while the Hook and Uniswap v4 handle the on-chain operations. The published contract allows users and reviewers to examine those operations independently of the interface.**
#### How KEYRING ONE Limit Orders Work
The on-chain process follows these stages:
1. The user submits an order through their connected wallet.
2. The Hook records the caller’s liquidity contribution.
3. Order assets are supplied to a narrow, initially out-of-range liquidity position.
4. Swaps moving the pool price through the range convert the supplied token into the other token.
5. When the range is fully crossed in the required direction, the Hook processes the fill and records the converted proceeds.
6. The user submits a withdrawal transaction to receive their share.
Before completion, the user can cancel their contribution and receive the principal returned by removing that liquidity. During partial conversion, this can include both tokens.
**Order placement → Pool liquidity → Token conversion → Fill accounting → Withdrawal**
**Order Placement Uses the PoolManager**
The contract inherits OpenZeppelin’s BaseHook and implements the PoolManager unlock callback interface:
```solidity
contract LimitOrderHook is BaseHook, IUnlockCallback {
```
During placement, `placeOrder()` requests a PoolManager callback:
```solidity
poolManager.unlock(
abi.encode(
CallbackData(
CallbackType.Place, abi.encode(PlaceCallbackData(key, msg.sender, zeroForOne, tick, liquidity))
)
)
);
```
The callback identifies the operation as `Place` and includes the pool, caller, direction, lower tick, and liquidity amount.
The Hook’s `unlockCallback()` dispatches placement to `_handlePlaceCallback()`, which adds liquidity and settles the supplied token with the PoolManager.
> **The pool, direction, tick, and liquidity submitted for an order are passed into on-chain placement. Users should review those order details before confirming, because they determine the position created by the transaction.**
**Order Assets Are Transferred to the PoolManager**
The published CurrencySettler dependency includes the following transfer for an external payer:
```solidity
IERC20(Currency.unwrap(currency)).safeTransferFrom(payer, address(poolManager), amount);
```
This transfers ERC-20 tokens from the payer to the PoolManager and requires an appropriate token allowance.
The tokens committed to an order have left the wallet and are used by the pool position. They are no longer available for the user to spend from that wallet while committed.
The Hook’s functions use caller addresses and order parameters. They do not require a private key as an input.
> **Tokens committed to an order are no longer available to spend from the user’s wallet. Users receive assets back through cancellation while their contribution is active or withdrawal after the order has been marked as filled.**
**Each User’s Contribution Is Recorded Separately**
When placing an order, the Hook updates both the total liquidity and the caller’s contribution:
```solidity
orderInfo.liquidityTotal += liquidity;
orderInfo.liquidity[msg.sender] += liquidity;
```
The active order ID is identified by the pool details, lower tick, and direction:
```solidity
return _orderIds[keccak256(abi.encode(key, tickLower, zeroForOne))];
```
Several users can contribute to the same active order range. Their liquidity is recorded separately by address.
This record determines the contribution a caller can cancel and their share of the proceeds after a fill.
> **Each user’s cancellation and withdrawal are based on their own recorded contribution, even when several users share the same order range. Canceling one user’s contribution does not cancel the contributions recorded for other users.**
**The Target Is Represented by a Narrow Liquidity Range**
The Hook adds liquidity across one tick-spacing interval:
```solidity
ModifyLiquidityParams({
tickLower: placeData.tickLower,
tickUpper: placeData.tickLower + key.tickSpacing,
liquidityDelta: int256(uint256(placeData.liquidity)),
salt: 0
})
```
The lower boundary is the order’s selected tick. The upper boundary is one `tickSpacing` above it.
The placement handler checks that the supplied assets match an out-of-range position in the requested direction. For example, its currency0-supply branch includes:
```solidity
if (principalDelta.amount1() != 0) revert InRange();
if (!placeData.zeroForOne) revert CrossedRange();
```
The other branch performs the corresponding checks for supplying currency1.
The order operates across the pool’s tick-defined price interval. A price touching part of that interval does not necessarily mean the order has fully completed.
> **An order operates across a narrow price interval. Users should not interpret a price touching part of that interval as full completion. Placement that fails the range or direction checks is rejected.**
**The Hook Supports Both Conversion Directions**
The placement function includes the `zeroForOne` direction parameter:
```solidity
function placeOrder(PoolKey calldata key, int24 tick, bool zeroForOne, uint128 liquidity) public virtual {
```
As documented in the source:
* `zeroForOne = true` supplies `currency0` and receives `currency1`.
* `zeroForOne = false` supplies `currency1` and receives `currency0`.
The pool’s token ordering determines which asset is currency0 or currency1. The direction parameter must therefore be interpreted together with the pool’s token pair.
> **The token pair and direction together determine which token an order supplies and which it receives. Users and reviewers need to interpret the direction alongside the token pair to identify the intended conversion.**
**A Fill Separates Converted Principal from LP Fees**
Inside `_fillOrder()`, the Hook removes the order liquidity and separates realized LP fees from principal:
```solidity
BalanceDelta principalDelta = fillDelta - feesAccrued;
```
It checks that no principal remains in the supplied currency and that the target-currency principal is nonnegative. For the currency0-to-currency1 direction:
```solidity
if (principal0 != 0 || principal1 < 0) {
revert UnexpectedFillDelta(zeroForOne, principal0, principal1);
}
```
The Hook then marks the order as filled and clears its active order mapping:
```solidity
orderInfo.filled = true;
_setOrderId(key, tickLower, zeroForOne, ORDER_ID_DEFAULT);
```
Positive converted principal is recorded as ERC-6909 claims belonging to the Hook. For example, for currency1:
```solidity
if (principal1 > 0) {
poolManager.mint(address(this), key.currency1.toId(), amount1 = uint128(principal1));
}
```
These claims are used to redeem the underlying tokens during withdrawal. The source notes that target-currency principal can round to zero due to integer rounding.
> **A filled order records the user’s share of converted principal, but does not automatically send the underlying tokens to the user’s wallet. The user must withdraw the proceeds, and the resulting amounts follow the contract’s integer-rounding rules.**
**Canceling Before Completion Removes the Caller’s Entire Contribution**
The `cancelOrder()` function reads the caller’s contribution and removes it from the order:
```solidity
uint128 liquidity = orderInfo.liquidity[msg.sender];
if (liquidity == 0) revert ZeroLiquidity();
delete orderInfo.liquidity[msg.sender];
orderInfo.liquidityTotal -= liquidity;
```
The cancellation callback removes that liquidity from the pool, separates LP fees, and transfers the returned principal to the specified recipient.
Before conversion, the returned principal is in the supplied token. During partial conversion, the returned principal can include both pool tokens, according to the position’s state when cancellation executes.
Cancellation removes the caller’s entire contribution to that active order. The function does not accept an amount for partial cancellation, and it leaves other users’ recorded contributions in place.
At contract level, exiting before completion uses `cancelOrder()`. The separate `withdraw()` function is reserved for orders marked as filled.
> **Users can exit before full completion and receive the principal returned by removing their liquidity, which may include both tokens. This removes the exiting user’s entire contribution to that active order, so no unconverted remainder of that contribution stays active.**
**Filled Proceeds Are Withdrawn According to the Caller’s Share**
The `withdraw()` function requires the order to be marked as filled and the caller to have a nonzero recorded contribution:
```solidity
if (!orderInfo.filled) revert NotFilled();
uint128 liquidity = orderInfo.liquidity[msg.sender];
if (liquidity == 0) revert ZeroLiquidity();
delete orderInfo.liquidity[msg.sender];
```
The caller’s share is calculated using the order’s remaining principal totals and liquidity:
```solidity
amount0 = FullMath.mulDiv(orderInfo.currency0Total, liquidity, liquidityTotal);
amount1 = FullMath.mulDiv(orderInfo.currency1Total, liquidity, liquidityTotal);
orderInfo.currency0Total -= amount0;
orderInfo.currency1Total -= amount1;
orderInfo.liquidityTotal -= liquidity;
```
Withdrawal amounts are rounded down. Any remainder stays in the remaining order totals for subsequent withdrawals, as described in the source.
The caller’s entire recorded share is cleared. The function does not take an amount for withdrawing only part of that share.
For a positive currency0 withdrawal, the callback burns the corresponding claims and transfers the underlying tokens:
```solidity
if (withdrawData.currency0Amount > 0) {
poolManager.burn(address(this), withdrawData.currency0.toId(), withdrawData.currency0Amount);
poolManager.take(withdrawData.currency0, withdrawData.to, withdrawData.currency0Amount);
}
```
The same structure applies to currency1.
> **A user’s withdrawal is calculated from the contribution recorded for the calling wallet. Another wallet cannot withdraw that recorded share merely by knowing the order ID. The operation redeems the caller’s entire share and sends the calculated proceeds to the specified recipient.**
**LP Fees Are Allocated to the Treasury**
All realized LP fees from these order positions are allocated to the protocol treasury. They are excluded from the principal that users can withdraw.
The treasury address is fixed at deployment:
```solidity
address public immutable treasury;
```
Placement, cancellation, and fill processing route realized fees through `_routeFeesToTreasury()`. Each call passes `true` for claim-based routing. For example:
```solidity
_routeFeesToTreasury(key, feesAccrued, true);
```
Inside the routing function, currency0 fees are handled through:
```solidity
key.currency0.take(poolManager, treasury, amount0Fee, asClaims);
```
The included CurrencySettler helper defines the choice between minting claims and transferring underlying tokens:
```solidity
claims ? poolManager.mint(recipient, currency.toId(), amount) : poolManager.take(currency, recipient, amount);
```
With claim-based routing enabled, the treasury receives ERC-6909 claims. An immediate underlying-token transfer to the treasury is not required during the user’s operation.
> **Users’ withdrawable principal excludes the LP fees allocated to the treasury. Separating the two makes clear which amounts belong to users’ order proceeds and which are protocol revenue. Claim-based fee routing also avoids requiring an immediate underlying-token transfer to the treasury during placement, cancellation, or fill processing.**
#### Additional Contract Checks
**Settlement Callbacks Are Restricted to the PoolManager**
The Hook’s settlement callback uses `onlyPoolManager`:
```solidity
function unlockCallback(bytes calldata rawData) public virtual onlyPoolManager returns (bytes memory returnData) {
```
The modifier is defined in the published BaseHook dependency:
```solidity
modifier onlyPoolManager() {
if (msg.sender != address(poolManager)) revert NotPoolManager();
_;
}
```
A caller other than the configured PoolManager is rejected.
> **Only the configured PoolManager can directly invoke this settlement callback. This restricts access to the callback that handles placement, cancellation, and withdrawal settlement for order assets.**
**Pool Details Must Reference This Hook**
The Hook validates the supplied pool key:
```solidity
function _validatePoolKey(PoolKey calldata key) internal view {
if (address(key.hooks) != address(this)) {
revert InvalidPoolHook();
}
}
```
This rejects pool keys that reference another Hook.
As noted in the source, this check does not itself confirm pool initialization. PoolManager operations perform the checks needed for an initialized pool.
> **A placement or cancellation request that references a different Hook is rejected. This prevents those operations from proceeding with a mismatched Hook reference; it does not establish that every pool or token is supported.**
**Native-Currency Pools Are Rejected**
During initialization, the Hook checks for native currency:
```solidity
if (key.currency0.isAddressZero()) revert NativeCurrencyNotSupported();
```
In the pool’s currency ordering, native currency occupies currency0, so this check rejects native-currency pairs.
The source also lists transfer-fee, rebasing, blacklisting, and pausing token behavior as outside the supported token assumptions. It explicitly states that these properties are not detected or enforced by the Hook.
> **Users cannot place orders through native-currency pools using this Hook. Token compatibility also matters: the native-currency check does not detect or reject every token behavior listed as unsupported in the source.**
#### Order Activity Can Be Reviewed On-Chain
The contract emits events for order operations and fee routing:
| Event | Recorded activity |
| -------------------- | ---------------------------------------------------- |
| `Place` | A caller adds an order contribution. |
| `Fill` | An active order is marked as filled. |
| `Cancel` | A caller cancels their contribution. |
| `Withdraw` | A caller redeems their share of a filled order. |
| `ProtocolFeesRouted` | Nonzero realized LP fees are routed to the treasury. |
The contract also provides read functions:
* **`getOrderId()`** returns the active order ID for a pool, lower tick, and direction.
* **`getOrderInfo()`** returns the filled status, currencies, remaining principal totals, and total liquidity.
* **`getOrderLiquidity()`** returns the contribution recorded for an address.
* **`getTickLowerLast()`** returns the pool’s last recorded lower tick.
For example:
```solidity
function getOrderLiquidity(OrderIdLibrary.OrderId orderId, address owner) external view returns (uint256) {
return _orderInfos[orderId].liquidity[owner];
}
```
> **Users can compare the order status shown in the interface with the contract’s records and transaction events. This provides an independent way to check their contributions and review placement, fill, cancellation, withdrawal, and fee-routing activity.**
## Why Open Source Matters
The Multisig Account audit and public LimitOrderHook source provide different forms of verification. The audit records an independent review of the specified multisig code, while the published Hook source allows its order logic to be examined directly.
The published code allows reviewers to examine the implementation behind the Limit Order feature, including:
* The Hook callbacks enabled for pool activity.
* How order assets are supplied and settled.
* How each address’s contribution is recorded.
* How tick ranges and conversion directions are represented.
* How fills are processed after pool swaps.
* How cancellation differs from withdrawal.
* How principal, rounding, and LP fees are accounted for.
* Which access checks and token assumptions apply.
BaseScan labels the published contract source as an exact match to the deployed bytecode. The hooklist issue provides a separate submission describing the Hook and its deployment address. Neither source verification nor a hooklist submission is a security audit.
> **Users can compare explanations of the feature with the actual implementation, or ask a technical reviewer to examine it. This helps them assess how their orders and associated assets are handled using the published rules.**
## Security Through Transparency
The published Hook and its dependencies allow developers and security professionals to inspect how order assets, contributions, fills, cancellation, withdrawals, and fees are handled. The separate BlockSec report documents the review of the specified Multisig Account contracts.
Public source code supports independent review. It does not by itself guarantee security or successful execution.
> **Users can examine the published Limit Order implementation and consult the independent Multisig Account audit. Each reference has a defined scope and supports an informed assessment of the corresponding feature.**
## How to Connect
KEYRING ONE currently connects only through KEYRING PRO Wallet. Users need KEYRING PRO Wallet to follow the connection process below.
#### Download KEYRING PRO Wallet
The following QR codes are provided for downloading KEYRING PRO Wallet on iOS and Android.
**For iOS**
**For Android**
#### Connect to KEYRING ONE
1. The user selects **Connect Wallet** in the top-right corner of KEYRING ONE.
2. In the **Connect Wallet** window, the user selects **Next**.
3. A WalletConnect QR code appears.
4. The user opens the **KEYRING PRO Wallet** app.
5. The user selects the account to connect.
6. The user selects **WalletConnect**.
7. The user scans the QR code displayed on KEYRING ONE.
8. When the **Verify Address** request appears, the user selects **Confirm**.
9. A verification request appears in KEYRING PRO Wallet.
10. The user signs the verification request to complete the connection.
