Main features

in-dapp wallets (burner and contract-based)

Apps built with Tasit use an autogenerated in-app account for the user to start with. It should never be the main place users hold their funds, and we don't ask you to back up the seed phrase for it.

Once the user has enough value that they shouldn't hold it with that account, it can be added as a signer to a contract-based account. This brings the benefits of contract-based wallets like Gnosis Safe and Argent to dapps.

This SDK takes an opinionated approach to onboarding (although since it's a modular repo, you still retain the ability to use other child packages and not the onboarding-related ones if you prefer). The SDK supports read-only mode, meta-transactions, contract-based accounts, and connecting with their preferred primary mobile Ethereum wallet.

This means a flow that users will be used to which decreases the friction for onboarding people who have used other Ethereum dapps.

in-dapp accounts

Using Tasit, you can generate a new Ethereum account and private key for the user.

Tasit makes it simple for a new account to be instantiated in each mobile app it is used in.

The intended UX is that this account should NOT have any significant amount of ETH, ERC20, or ERC721 tokens sent to it. Instead, this address should be authorized to perform actions on behalf of a contract-based account or software wallet a user already has with some ETH or tokens. This is an ephemeral account for that app on the device, and as the user gets more familiar with it their account can be progressively upgraded to a contract-based account later or their funds can be stored in their preferred primary software wallet.

For users without any ETH or tokens, any costs the user incurs at first should be subsidized.

For more info, see @tasit/account.

This means fewer steps that need to be taken to onboard a new user.

in-dapp contract-based accounts

Give them a contract-based account so that the UX around securing keys and recovering funds is simpler.

For example, set up a Gnosis Safe for the user.

const { address: burnerWalletAddress } = burnerWallet;
const username = "paul";
const contractKind = "gnosis-safe"; // | "argent" | "abridged" | "authereum" | ...
const create2ContractBasedAccount = await Account.upgrade({
account: burnerWalletAddress,
username: username,
contractKind: contractKind
});
console.log(create2ContractBasedAccount.address); // Send it an ERC20 token!
const contractBasedAccount = await create2ContractBasedAccount.deploy();
console.log(contractBasedAccount.ensName); // paul.{NAMEOFTHISDAPP}.eth

For more info, see @tasit/contract-based-account.

Here's an example app using the account and contract-based account functionality from tasit.

Optimistic UI

Tasit provides JavaScript/TypeScript middleware for reading from and writing to smart contracts (and listening to events) through an expressive pub/sub API.

import { Contract } from "tasit";
const { NFT } = Contract;
const contractAddress = "0x0E86...333";
const contract = new NFT(contractAddress);
// No await???
const action = contract.safeTransferFrom(/*...*/);
action.on("error", errorListener);
action.on("oneConfirmation", goodSignListener);
action.on("enoughConfirmations", successListener);
action.send(); // broadcast
// Do optimistic UI updates immediately, while making sure
// to update the UI again when there are enough
// confirmations for your use case
// ...

As a mobile developer, using Tasit to interact with the backend should be as simple as using Firebase as a backend-as-a-service. This library is written in such a way that the developer using the SDK can just think about writing data and listening for more data. The fact that there's a blockchain powering this is an implementation detail that is abstracted away.

This middleware wraps the core ethers.js contract API for making JSON-RPC requests.

Fore more info, see @tasit/action.

This makes the experience for new developers working on a mobile app with Tasit simpler, which means more mobile dapps for end users.

Start in read-only mode

A native mobile dapp should be read-only for as long as possible. The user shouldn't know there's a blockchain involved or see anything about an account, and an Ethereum account shouldn't even be created until it becomes necessary. Why go through an onboarding flow at all right away?

The flow for reading data from The Graph or directly from contracts without onboarding first just works with no special configuration.

For more info, see @tasit/action.


Go back to the home page of the docs.