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

Add docs for omni-transaction-rs + near example #2289

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 1 commit
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
Prev Previous commit
Next Next commit
small changes
  • Loading branch information
PiVortex committed Nov 29, 2024
commit ea035399e14a09067d5b08e6ad73ce9f3c35ab47
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: Controlling a NEAR account
sidebar_label: Overview
---

This example is of a `simple subscription service` that allows a user to subscribe to an arbitrary service and allows the contract to charge them 5 NEAR tokens every month; sort of like a standing order. For most chains an account has a single key, the power of NEARs account model combined with chain signatures is that you can add an `MPC controlled key` to your account allowing a smart contract to control your account through code and limited actions (including ones that require a full access key to sign). You can also derive and use new implicit NEAR accounts via the MPC contract as you do with other chains but this use case is more interesting.
This example is of a `simple subscription service` that allows a user to subscribe to an arbitrary service and lets the contract to charge them 5 NEAR tokens every month; sort of like a standing order. For most chains an account has a single key, the power of NEARs account model combined with chain signatures is that you can add an `MPC controlled key` to your account allowing a smart contract to control your account through code and limited actions (including ones that require a full access key to sign).

This concept also enables:
- **Account recovery**: allow a contract to add a new private key to your account after preset conditions are met.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,13 +13,13 @@

---

# Passing relevant information to the contract
## Passing relevant information to the contract

Transactions need some information that can only be fetched off chain such as the nonce and other information that is easiest to fetch off chain like the addresses. This information can be passed to the contract as arguments. Each chain creates transactions differently so the information that needs to be passed to the contract will be different for each chain.

---

# Constructing a transaction
## Constructing a transaction

The library implements a transaction builder for each chain.

Expand All @@ -38,7 +38,7 @@

---

# Building the payload
## Building the payload

Once the transaction is built you next need to construct the payload that will be sent to the MPC contract.

Expand All @@ -57,7 +57,7 @@
---


# Calling the MPC contract
## Calling the MPC contract

Now we have the payload we can request it to be signed by the MPC contract using the `sign` method.

Expand All @@ -77,7 +77,7 @@

---

# Reconstructing the signature
## Reconstructing the signature

Note that this step is optional. You can decide to reconstruct the signature and add it to the transaction in the contract or the client, but an advantage of doing it in the contract is that you can return a fully signed transaction from the contract which can be straight away braodcasted to the network instead of having to store the transaction in the frontend. This also makes it much easier for indexers/relayers to get transactions and broadcast them.

Expand All @@ -92,11 +92,11 @@

<Github language="rust" url=""start="" end="" />

Then the callback will recieve the result from the mpc contract and the transaction and check that the result is ok.

Check failure on line 95 in docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md

View workflow job for this annotation

GitHub Actions / runner / misspell

[misspell] reported by reviewdog 🐶 "recieve" is a misspelling of "receive" Raw Output: ./docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md:95:23: "recieve" is a misspelling of "receive"

<Github language="rust" url=""start="" end="" />

Now the tranasction is converted back into is respective transaction structure the individual parts of the singature are reconstructed into a single signature and the singature is added to the transaction and returned from the contract.

Check failure on line 99 in docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md

View workflow job for this annotation

GitHub Actions / runner / misspell

[misspell] reported by reviewdog 🐶 "singature" is a misspelling of "signature" Raw Output: ./docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md:99:107: "singature" is a misspelling of "signature"

Check failure on line 99 in docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md

View workflow job for this annotation

GitHub Actions / runner / misspell

[misspell] reported by reviewdog 🐶 "singature" is a misspelling of "signature" Raw Output: ./docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures-contract/overiew.md:99:167: "singature" is a misspelling of "signature"

<Tabs groupId="code-tabs">
<TabItem value="Ξ Ethereum">
Expand All @@ -114,13 +114,13 @@

---

# Relaying the signed transaction
## Relaying the signed transaction



---

# Cookbook
## Cookbook
:::info Cookbook

Further examples of building different transactions can be found in the [cookbook](https://github.com/Omni-rs/examples/tree/main).
Expand Down
Loading