diff --git a/concepts/sub-organizations.mdx b/concepts/sub-organizations.mdx index 6f7b2ce5..07b7db1b 100644 --- a/concepts/sub-organizations.mdx +++ b/concepts/sub-organizations.mdx @@ -1,6 +1,6 @@ --- title: "Sub-Organizations" -description: "Using Turnkey’s flexible infrastructure, you can programmatically create and manage sub-organizations for your end-users. sub-organizations aren't subject to size limits: you can create as many sub-organizations as needed. The parent organization has **read-only** visibility into all of its sub-organizations, and activities performed in sub-organizations roll up to the parent for billing purposes." +description: "Using Turnkey's flexible infrastructure, you can programmatically create and manage sub-organizations for your end-users. sub-organizations aren't subject to size limits: you can create as many sub-organizations as needed. The parent organization has **read-only** visibility into all of its sub-organizations, and activities performed in sub-organizations roll up to the parent for billing purposes." --- We envision sub-organizations being very useful to model your End-Users if you're a business using Turnkey for key management. Let's explore how. @@ -9,10 +9,10 @@ We envision sub-organizations being very useful to model your End-Users if you'r Creating a new sub-organization is an activity performed by the parent organization. The activity itself takes the following attributes as inputs: -* organization name -* a list of root users -* a root quorum threshold -* \[optional] a wallet (note: in versions prior to V4, this was a private key) +- organization name +- a list of root users +- a root quorum threshold +- \[optional] a wallet (note: in versions prior to V4, this was a private key) Root users can be programmatic or human, with one or many credentials attached. @@ -22,4 +22,13 @@ Root users can be programmatic or human, with one or many credentials attached. ## Deleting Sub-Organizations -To delete sub-organizations you can call the [delete sub-organization activity](/api-reference/organizations/delete-sub-organization). Before deleting a sub-organization all private keys and wallets within the sub-organization must have been exported to prevent loss of funds, or you can pass in the `deleteWithoutExport` parameter with the value `true` to override this. The `deleteWithoutExport` parameter, if not passed in, is default `false`. Note that this activity must be initiated by the sub-organization that is to be deleted. +To delete a sub-organization, you can use the [delete sub-organization activity](/api-reference/organizations/delete-sub-organization). +Before proceeding, ensure that all private keys and wallets within the sub-organization have been exported to prevent any loss of funds. +Alternatively, you can set the `deleteWithoutExport` parameter to `true` to bypass this requirement. +By default, the `deleteWithoutExport` parameter is set to `false`. + + + This activity must be initiated by a root user in the sub-organization that is + to be deleted. A parent org cannot delete a sub-organization without its + participation. + diff --git a/docs.json b/docs.json index 7063ab7c..29d005ae 100644 --- a/docs.json +++ b/docs.json @@ -1,6 +1,6 @@ { "$schema": "https://mintlify.com/docs.json", - "theme": "maple", + "theme": "mint", "name": "Turnkey", "colors": { "primary": "#6a5bf5", @@ -31,7 +31,6 @@ }, "getting-started/examples", "getting-started/launch-checklist" - ] }, { @@ -444,16 +443,13 @@ "groups": [ { "group": "Changelog", - "pages": [ - "changelog" - ] + "pages": ["changelog"] } ] } ], "global": { "anchors": [ - { "anchor": "Community", "href": "https://join.slack.com/t/clubturnkey/shared_invite/zt-2837d2isy-gbH60kJ~XnXSSFHiqVOrqw", diff --git a/ecosystems/framework.mdx b/ecosystems/framework.mdx index cf07366f..c3b13ee2 100644 --- a/ecosystems/framework.mdx +++ b/ecosystems/framework.mdx @@ -5,10 +5,9 @@ description: "Turnkey operates at the **cryptographic curve** level rather that ## Introduction - We are continuously evaluating and adding support for emerging assets and protocols. If there are specific cryptocurrencies you'd like to see us offer deeper support for, please let us know by contacting us at [hello@turnkey.com](mailto:hello@turnkey.com), on [X](https://x.com/turnkeyhq/), or [on Slack](https://join.slack.com/t/clubturnkey/shared_invite/zt-2837d2isy-gbH60kJ~XnXSSFHiqVOrqw). -## What is Turnkey’s approach to supporting crypto assets? +## What is Turnkey's approach to supporting crypto assets? Turnkey follows a tiered approach to supporting digital assets, ranging from supporting cryptographic curve support, to advanced transaction parsing and policy management. Each tier deepens the level of functionality, as outlined below: @@ -30,29 +29,59 @@ Our SDK provides tools and scripts to help in constructing and signing basic tra At our highest level of support, Turnkey offers the ability to parse transactions and define custom policies based on transaction parameters. -| Tier | Depth of support | EVM   | SVM   | BTC   | ATOM | TRON | SUI    | APT   | -| ------ | :------------------------------- | ----- | ----- | ----- | ---- | ---- | ------ | ----- | -| Tier 1 | Curve-level | | | | | | | | -| Tier 2 | Address derivation | | | | | | | | -| Tier 3 | SDK construction and signing | | | | | | | | -| Tier 4 | Transaction parsing and policies | | | | | | | | +| Tier | Depth of support | EVM | SVM | BTC | ATOM | TRON | SUI | APT | MOVE | +| ------ | :------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | +| Tier 1 | Curve-level | | | | | | | | | +| Tier 2 | Address derivation | | | | | | | | | +| Tier 3 | SDK construction and signing | | | | | | | | | +| Tier 4 | Transaction parsing and policies | | | | | | | | | For more details about each ecosystem, refer to the pages below: - + Overview - + Ethereum (EVM) support on Turnkey - + Solana (SVM) support on Turnkey - + Bitcoin support on Turnkey - + Specific support for other ecosystems on Turnkey diff --git a/getting-started/launch-checklist.mdx b/getting-started/launch-checklist.mdx index 4d93827e..09263ca2 100644 --- a/getting-started/launch-checklist.mdx +++ b/getting-started/launch-checklist.mdx @@ -5,25 +5,30 @@ description: "Before deploying your Turnkey integration in production, take a lo ## Production Setup -* Many of our customers prefer to maintain separate Development and Production [organizations](/concepts/organizations). If you choose to do so, ensure your production environment is referencing the correct organization ID. -* Ensure you have an active subscription via the Account Settings page in the Turnkey dashboard. -* If you are on an Enterprise plan, confirm your production organization ID with your account rep. -* Double check our [resource limits](/concepts/resource-limits) and [rate limits](/faq#do-you-have-any-rate-limits-in-place-in-your-public-api) to ensure your implementation will not trigger these limits at production scale. +- Many of our customers prefer to maintain separate Development and Production [organizations](/concepts/organizations). If you choose to do so, ensure your production environment is referencing the correct organization ID. +- Ensure you have an active subscription via the Account Settings page in the Turnkey dashboard. +- If you are on an Enterprise plan, confirm your production organization ID with your account rep. + + + Double check our [resource limits](/concepts/resource-limits) and [rate + limits](/faq#do-you-have-any-rate-limits-in-place-in-your-public-api) to + ensure your implementation will not trigger these limits at production scale. + ## Security -* Lock down your [root quorum](/concepts/users/root-quorum). We recommend a quorum of at least 3 with a threshold of at least 2. -* Ensure any team members with critical permissions, especially root quorum members, have set up at least two authenticators for their account (e.g., touchID plus a hardware authenticator like a Yubikey). -* Avoid using root user permissions for routine operations and instead use standard users with permissions explicitly granted via policies to limit the surface area of a compromised user. -* Confirm that all API keys are stored securely and not embedded in exposed or vulnerable parts of the codebase. API keys should be stored in a secure, encrypted environment and should never be hard-coded in publicly accessible repositories or client-side code. +- Lock down your [root quorum](/concepts/users/root-quorum). We recommend a quorum of at least 3 with a threshold of at least 2. +- Ensure any team members with critical permissions, especially root quorum members, have set up at least two authenticators for their account (e.g., touchID plus a hardware authenticator like a Yubikey). +- Avoid using root user permissions for routine operations and instead use standard users with permissions explicitly granted via policies to limit the surface area of a compromised user. +- Confirm that all API keys are stored securely and not embedded in exposed or vulnerable parts of the codebase. API keys should be stored in a secure, encrypted environment and should never be hard-coded in publicly accessible repositories or client-side code. ## Logging -* Key identifiers in our service include sub-organization IDs, wallet IDs and addresses. Ensure these identifiers are securely stored, associated with your users as necessary. -* Set up logging for activities and include relevant identifiers needed for audit, compliance, or troubleshooting purposes. We recommend logging activity IDs, status, creation date, as well as credential IDs and public keys of the approvers. You should also log other resource IDs if relevant for your data model (policies, tags, wallets, accounts, etc) +- Key identifiers in our service include sub-organization IDs, wallet IDs and addresses. Ensure these identifiers are securely stored, associated with your users as necessary. +- Set up logging for activities and include relevant identifiers needed for audit, compliance, or troubleshooting purposes. We recommend logging activity IDs, status, creation date, as well as credential IDs and public keys of the approvers. You should also log other resource IDs if relevant for your data model (policies, tags, wallets, accounts, etc) ## Errors and Retries -* Activity submission is optimistically synchronous. In most cases activities will be completed and returned right away (synchronously), but if there is a lot of activity in a single organization, activities will be processed asynchronously. Make sure you handle PENDING activities by polling a few times until their completion. You can use [createActivityPoller](https://github.com/tkhq/sdk/blob/d9ed2aefc92d298826a40e821f959b019ea1936f/packages/http/src/async.ts#L101) to do this if you're using our Typescript SDK. -* Implement retry strategies for API calls, adjusting for various error types and avoiding over-retrying on critical failures. Incorporate [rate limiting](/faq#do-you-have-any-rate-limits-in-place-in-your-public-api) and exponential backoff in retry mechanisms. -* Set up monitoring to detect and alert on patterns of failures +- Activity submission is optimistically synchronous. In most cases activities will be completed and returned right away (synchronously), but if there is a lot of activity in a single organization, activities will be processed asynchronously. Make sure you handle PENDING activities by polling a few times until their completion. You can use [createActivityPoller](https://github.com/tkhq/sdk/blob/d9ed2aefc92d298826a40e821f959b019ea1936f/packages/http/src/async.ts#L101) to do this if you're using our Typescript SDK. +- Implement retry strategies for API calls, adjusting for various error types and avoiding over-retrying on critical failures. Incorporate [rate limiting](/faq#do-you-have-any-rate-limits-in-place-in-your-public-api) and exponential backoff in retry mechanisms. +- Set up monitoring to detect and alert on patterns of failures diff --git a/home.mdx b/home.mdx index 2e253f16..b97ce4e6 100644 --- a/home.mdx +++ b/home.mdx @@ -11,8 +11,8 @@ sidebarTitle: "Welcome" - - + +