jcarbonnell/preTrainingNEAR huggingface dataset:
---
sidebar_position: 5
sidebar_label: Transaction
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

# `Transaction` Structure

## Definition

Transaction is the main way of interraction between a user and a blockchain. Transaction contains:
- Signer account ID
- Receiver account ID
- Actions

## `SignedTransactionView`

Transaction might be unsigned but from the indexer perspective when we think about Transaction we think about signed one

<Tabs>
  <TabItem value="rust" label="Rust">

```rust links=1
pub struct SignedTransactionView {
    pub signer_id: AccountId,
    pub public_key: PublicKey,
    pub nonce: Nonce,
    pub receiver_id: AccountId,
    pub actions: Vec<ActionView>,
    pub signature: Signature,
    pub hash: CryptoHash,
}
```

  </TabItem>
  <TabItem value="typescript" label="TypeScript">

```ts links=1
export type Transaction = {
  signerId: string;
  publicKey: string;
  nonce: number;
  receiverId: string;
  actions: Action[];
  signature: string;
  hash: string;
};
```

  </TabItem>
</Tabs>


## `ActionView`

`ActionView` is an Enum with possible actions along with parameters. This structure is used in Transactions and in [Receipts](receipt.mdx)

<Tabs>
  <TabItem value="rust" label="Rust">

```rust links=1
pub enum ActionView {
    CreateAccount,
    DeployContract {
        code: String,
    },
    FunctionCall {
        method_name: String,
        args: String,
        gas: Gas,
        #[serde(with = "u128_dec_format")]
        deposit: Balance,
    },
    Transfer {
        #[serde(with = "u128_dec_format")]
        deposit: Balance,
    },
    Stake {
        #[serde(with = "u128_dec_format")]
        stake: Balance,
        public_key: PublicKey,
    },
    AddKey {
        public_key: PublicKey,
        access_key: AccessKeyView,
    },
    DeleteKey {
        public_key: PublicKey,
    },
    DeleteAccount {
        beneficiary_id: AccountId,
    },
}
```

  </TabItem>
  <TabItem value="typescript" label="TypeScript">

```ts links=1
export type Action =
  | "CreateAccount"
  | DeployContractAction
  | FunctionCallAction
  | TransferAction
  | StakeAction
  | AddKeyAction
  | DeleteKeyAction
  | DeleteAccountAction;

export type DeployContractAction = {
  DeployContract: {
    code: string;
  };
};

export type FunctionCallAction= {
  FunctionCall: {
    methodName: string;
    args: string;
    gas: number;
    deposit: string;
  };
};

export type TransferAction = {
  Transfer: {
    deposit: string;
  };
};

export type StakeAction = {
  Stake: {
    stake: number;
    publicKey: string;
  };
};

export type AddKeyAction = {
  AddKey: {
    publicKey: string;
    accessKey: AccessKey;
  };
};

export type DeleteKeyAction = {
  DeleteKey: {
    publicKey: string;
  };
};

export type DeleteAccountAction = {
  DeleteAccount: {
    beneficiaryId: string;
  };
};
```

  </TabItem>
</Tabs>
- Proposal Name: NEAR economics specs
- Start Date: 2020-02-23
- NEP PR: [nearprotocol/neps#0000](https://github.com/nearprotocol/NEPs/pull/33)
- Issue(s): link to relevant issues in relevant repos (not required).

# Summary

[summary]: #summary

Adding economics specification for NEAR Protocol based on the NEAR whitepaper - https://pages.near.org/papers/the-official-near-white-paper/#economics

# Motivation

[motivation]: #motivation

Currently, the specification is defined by the implementation in https://github.com/near/nearcore. This codifies all the parameters and formulas and defines main concepts.

# Guide-level explanation

[guide-level-explanation]: #guide-level-explanation

The goal is to build a set of specs about NEAR token economics, for analysts and adopters, to simplify their understanding of the protocol and its game-theoretical dynamics.
This initial release will be oriented to validators and staking in general.

# Reference-level explanation

[reference-level-explanation]: #reference-level-explanation

This part of the documentation is self-contained. It may provide material for third-party research papers, and spreadsheet analysis.

# Drawbacks

[drawbacks]: #drawbacks

We might just put this in the NEAR docs.

# Rationale and alternatives

[rationale-and-alternatives]: #rationale-and-alternatives

# Unresolved questions

[unresolved-questions]: #unresolved-questions

# Future possibilities

[future-possibilities]: #future-possibilities

This is an open document which may be used by NEAR's community to pull request a new economic policy. Having a formal document also for non-technical aspects opens new opportunities for the governance.
Register for NEAR’s June Town Hall: NEAR at Consensus
COMMUNITY
June 3, 2022
Howdy, NEAR World! This month the NEAR Town Hall will be broadcasting from Coindesk’s Consensus conference in Austin, Texas. Join us on Sunday, June 12, 2022 at 5:00pm GMT (1:00PM EDT/10:00PM PDT) for updates on the NEAR ecosystem and Web3 onboarding efforts, as well as for special Consensus-related segments. 

Here’s a brief preview of what to expect from the June Town Hall. And don’t forget to register for the Town Hall below. 

State of NEAR address
NEAR Foundation CEO Marieke Flament will open the June Town Hall with a brief segment on why NEAR is thrilled to be a Level 5 sponsor of Consensus. She will also give developers, projects, and investors ecosystem updates, and remind the community of its shared vision of mainstreaming Web3 technology and apps. 

Flament’s segment will be a “State of NEAR”. In this segment, which comes at the mid-year point, Flament will reflect on NEAR’s tremendous growth. She will also address the bear market and speak of NEAR’s solid fundamentals for funding, support, marketing, and more. 

To round out her Town Hall spot, Flament will also highlight NEAR’s presence and interactions at this year’s Consensus gathering.

NEAR Protocol update
Following Flament’s introduction, NEAR Co-founder Illia Polosukhin will give a mid-year overview and update on NEAR’s Nightshade sharding. He will also touch on what to expect from the NEAR Protocol throughout the rest of 2022 and into 2023. 

This Town Hall segment will be must-see for both new and prospective developers, projects, and investors curious about the state of NEAR’s scalability and security. 

NEAR Foundation updates
After Illia’s NEAR Protocol update, the Town Hall will pivot into NEAR Foundation updates. Jack Collier, NEAR Foundation’s new CMO, will get into a number of new and exciting foundation activities. After he shares his vision for the foundation’s marketing efforts.  

Yadira Blocker, the foundation’s Experiential Marketing and Events Lead, will update the community on upcoming events. Her segment will feature spots on Ethereum Community Conference (EthCC) and NEARCON, including where to find information on these events and how to stay updated as they approach. 

Blocker will also give an introduction to the NEAR Town Hall’s Consensus Spotlight. 

Consensus Spotlight and Town Hall Panel
This special Town Hall segment will feature “man on the street” video interviews from Consensus. They will feature NEAR Foundation team members David Morrison (Community Moderator) and Chad Lamon (Video Producer). 

After the video segment, Marieke Flament will introduce the Town Hall panel. Moderated by Cathy Hackl, a Tech Columnist and Thought Leader, this special panel will include a team of globally acclaimed and awarded creatives announcing their project on NEAR. So, be sure to tune in to the Town Hall to see what this super stealth and exciting project is all about.
```bash
near call v2.keypom.near create_drop '{"public_keys": <PUBLIC_KEYS>, "deposit_per_use": "10000000000000000000000", "fcData": {"methods": [[{"receiverId": "nft.primitives.near","methodName": "nft_mint","args": {"token_id": "1", "metadata": {"title": "My NFT drop","description": "","media": ""}, "accountIdField": "receiver_id", "attachedDeposit": "10000000000000000000000"}]]}}' --depositYocto 23000000000000000000000 --gas 100000000000000 --accountId bob.near
```
# Miscellaneous API

```rust
value_return(value_len: u64, value_ptr: u64)
```

Sets the blob of data as the return value of the contract.

###### Panics

- If `value_len + value_ptr` exceeds the memory container or points to an unused register it panics with `MemoryAccessViolation`;

---

```rust
panic()
```

Terminates the execution of the program with panic `GuestPanic("explicit guest panic")`.

---

```rust
panic_utf8(len: u64, ptr: u64)
```

Terminates the execution of the program with panic `GuestPanic(s)`, where `s` is the given UTF-8 encoded string.

###### Normal behavior

If `len == u64::MAX` then treats the string as null-terminated with character `'\0'`;

###### Panics

- If string extends outside the memory of the guest with `MemoryAccessViolation`;
- If string is not UTF-8 returns `BadUtf8`.
- If string length without null-termination symbol is larger than `config.max_log_len` returns `BadUtf8`.

---

```rust
log_utf8(len: u64, ptr: u64)
```

Logs the UTF-8 encoded string.

###### Normal behavior

If `len == u64::MAX` then treats the string as null-terminated with character `'\0'`;

###### Panics

- If string extends outside the memory of the guest with `MemoryAccessViolation`;
- If string is not UTF-8 returns `BadUtf8`.
- If string length without null-termination symbol is larger than `config.max_log_len` returns `BadUtf8`.

---

```rust
log_utf16(len: u64, ptr: u64)
```

Logs the UTF-16 encoded string. `len` is the number of bytes in the string.
See https://stackoverflow.com/a/5923961 that explains that null termination is not defined through encoding.

###### Normal behavior

If `len == u64::MAX` then treats the string as null-terminated with two-byte sequence of `0x00 0x00`.

###### Panics

- If string extends outside the memory of the guest with `MemoryAccessViolation`;

---

```rust
abort(msg_ptr: u32, filename_ptr: u32, line: u32, col: u32)
```

Special import kept for compatibility with AssemblyScript contracts. Not called by smart contracts directly, but instead
called by the code generated by AssemblyScript.

# Future Improvements

In the future we can have some of the registers to be on the guest.
For instance a guest can tell the host that it has some pre-allocated memory that it wants to be used for the register,
e.g.

```rust
set_guest_register(register_id: u64, register_ptr: u64, max_register_size: u64)
```

will assign `register_id` to a span of memory on the guest. Host then would also know the size of that buffer on guest
and can throw a panic if there is an attempted copying that exceeds the guest register size.
```js
import { Wallet } from './near-wallet';

const KEYPOM_CONTRACT_ADDRESS = "v2.keypom.near";
const DROP_AMOUNT = "10000000000000000000000"; // 0.1 NEAR

const wallet = new Wallet({ createAccessKeyFor: KEYPOM_CONTRACT_ADDRESS }); 

await wallet.callMethod({
  method: "create_drop",
  contractId: KEYPOM_CONTRACT_ADDRESS,
  args: {
    public_keys: state.publicKeys,
    deposit_per_use: DROP_AMOUNT,
  },
  deposit: "23000000000000000000000" // state.publicKeys.length * dropAmount + 3000000000000000000000,
  gas: "100000000000000",
});
```

_The `Wallet` object comes from our [quickstart template](https://github.com/near-examples/hello-near-examples/blob/main/frontend/near-wallet.js)_
AI is NEAR: Illia Polosukhin on AI and the Open Web at NEARCON ’23
NEAR FOUNDATION
October 26, 2023
Artificial Intelligence and Web3 have been two of the hottest topics of 2023. There has been significant interest in how the two technology ecosystems may converge in the coming years, with lots of interest from investors.

For NEARCON ‘23, we’ve designed a special track for AI and the open web: ”AI is NEAR”. Leading the way will be NEAR co-founder Illia Polosukhin, a pioneer in the world of AI. 

Illia will share his perspective on this past year’s AI revolution, including its intersection with the Web3 space on NEAR in the months to come. 

Attention Is All You need
By now, everyone knows ChatGPT, which kicked off the latest AI revolution. But years before OpenAI released its AI chatbot, a group of researchers published a paper that would revolutionize the fields of AI and machine learning. 

The “Attention is All You Need” paper, of which Illia is a co-author, introduced transformers — the “T” in ChatGPT. Illia’s research was instrumental in laying the groundwork for the major LLMs of today, such as ChatGPT and Bard. 

At NEARCON ‘23, Illia will draw on his deep expertise in AI to offer a perspective on how AI and Web3 will converge and how blockchains can help AI develop in a more positive direction, mitigating potential risks and introducing more transparency. He will share the strategy for AI on NEAR going forward, including evolving NEAR governance with AI agents and the emergence of new business models. 

Illia Polosukhin and TechCrunch’s Mike Butcher in a fireside chat
In this candid discussion, Illia and TechCrunch’s Mike Butcher will explore the evolving role of AI in the open web, what we can expect next, and why the current state of AI controlled by major corporations needs to change. 

As the case for open source AI becomes clearer, and as regulators across the globe mitigate risk with new policies, the question now becomes: how can Web3 help AI evolve in a more positive direction?

Join the AI and Open Web chat at NEARCON ‘23
With some of the brightest thought leaders in AI and the open web, NEARCON ‘23 is one not to be missed. Alongside Illia, you will also hear from NEAR co-founder Alex Skidanov, who is currently working on an AI startup that is building smarter large language models, or LLMs, in a more decentralized way. 

There will also be a panel discussion on how AI and blockchain technologies will integrate with modern work environments. Niraj Pant, previously an investor at Polychain who is launching a startup at the intersection of AI and Web3, will also deliver a keynote on how AI can be leveraged for decentralized applications and services.

The full NEARCON ‘23 schedule is now live, so check out the other tracks!

If you’re a student in Spain or Portugal, or a Ukrainian citizen living in Portugal, you’re eligible for free tickets. Hackers also get in for free by applying to the NEARCON IRL Hackathon.
---
sidebar_position: 4
---

# Deploying Contracts

You might want your smart contract to deploy subsequent smart contract code for a few reasons:

* The contract acts as a Factory, a pattern where a parent contract creates many child contracts ([Mintbase](https://www.mintbase.io/) does this to create a new NFT store for anyone who wants one; [Rainbow Bridge](https://near.org/bridge/) does this to deploy separate Fungible Token contracts for [each bridged token](https://github.com/aurora-is-near/rainbow-token-connector/blob/ce7640da144f000e0a93b6d9373bbc2514e37f3b/bridge-token-factory/src/lib.rs#L311-L341))
* The contract [updates its own code](../../../2.build/2.smart-contracts/release/upgrade.md#programmatic-update) (calls `deploy` on itself).
* You could implement a "contract per user" system that creates app-specific subaccounts for users (`your-app.user1.near`, `your-app.user2.near`, etc) and deploys the same contract to each. This is currently prohibitively expensive due to NEAR's [storage fees](https://docs.near.org/concepts/storage/storage-staking), but that may be optimized in the future. If it is, this sort of "sharded app design" may become the more scalable, user-centric approach to contract standards and app mechanics. An early experiment with this paradigm was called [Meta NEAR](https://github.com/metanear).

If your goal is to deploy to a subaccount of your main contract like Mintbase or the Rainbow Bridge, you will also need to create the account. So, combining concepts from the last few pages, here's what you need:

```rust
const CODE: &[u8] = include_bytes!("./path/to/compiled.wasm");

Promise::new("subaccount.example.near".parse().unwrap())
    .create_account()
    .add_full_access_key(env::signer_account_pk())
    .transfer(3_000_000_000_000_000_000_000_000) // 3e24yN, 3N
    .deploy_contract(CODE.to_vec())
```

Here's what a full contract might look like, showing a naïve way to pass `code` as an argument rather than hard-coding it with `include_bytes!`:

```rust
use near_sdk::{env, near_bindgen, AccountId, Balance, Promise};

const INITIAL_BALANCE: Balance = 3_000_000_000_000_000_000_000_000; // 3e24yN, 3N

#[near_bindgen]
pub struct Contract {}

#[near_bindgen]
impl Contract {
    #[private]
    pub fn create_child_contract(prefix: AccountId, code: Vec<u8>) -> Promise {
        let subaccount_id = AccountId::new_unchecked(
          format!("{}.{}", prefix, env::current_account_id())
        );
        Promise::new(subaccount_id)
            .create_account()
            .add_full_access_key(env::signer_account_pk())
            .transfer(INITIAL_BALANCE)
            .deploy_contract(code)
    }
}
```

Why is this a naïve approach? It could run into issues because of the 4MB transaction size limit – the function above would deserialize and heap-allocate a whole contract. For many situations, the `include_bytes!` approach is preferable. If you really need to attach compiled Wasm as an argument, you might be able to copy the approach [used by Sputnik DAO v2](https://github.com/near-daos/sputnik-dao-contract/blob/a8fc9a8c1cbde37610e56e1efda8e5971e79b845/sputnikdao2/src/types.rs#L74-L142).
NEAR Foundation and Seracle Team to Nurture the Web3 Ecosystem with DevOps Efficiency
NEAR FOUNDATION
June 7, 2023
NEAR Foundation and Seracle, a top blockchain cloud platform, have established a partnership to revolutionize the world of Web3 development. This alliance, forged in the name of innovation and cost-efficiency, capitalizes on Seracle’s unique Litenode architecture.

This groundbreaking technology aims to drive down costs, with the potential for reducing a project’s monthly expenditures on node maintenance and DevOps by up to 90%.

Introducing the Litenode and the Web3 Incubation Center
The Litenode architecture is one of the linchpins in this strategic collaboration. Its design facilitates dramatic cost savings, all while ensuring quality isn’t compromised. But it doesn’t stop there. 

The integration of a Web3 incubation center, nestled in the bustling tech hub of Pune, India, gives developers access to a fertile innovation environment. This collaborative center presents developers with a unique opportunity to immerse themselves in a vibrant ecosystem dedicated to the development, learning, and scaling of Web3 projects.

“Seracle’s enthusiasm, technical capabilities, and experience in the Web3 space make them an ideal partner to grow NEAR,” said Arpit Sharma, Managing Director of APAC, MENA of NEAR Foundation, expressing enthusiasm for the collaboration’s potential. 

This partnership, with its focus on communal growth and knowledge sharing, is poised to cultivate an enriched community of developers ready to take on the challenges of the Web3 landscape.

How NEAR and Seracle are financing the next wave of Web3 
To bring these ambitions to fruition, financial support is vital. Seracle has committed to providing substantial backing, offering platform credits from a pool of $100,000. These credits serve to alleviate the financial burdens of upfront costs, letting developers channel their focus into the creative process. 

NEAR Foundation, in step with this initiative, pledges to offer grants to select innovative projects based at Seracle’s incubation center. Looking ahead, the partnership has set its sights high. The ambitious goal to onboard around 100 Web3 projects and engage with 5,000 developers this year underscores the commitment to growth and innovation. 

Shrikant Bhalerao, CEO of Seracle, shares this vision and expresses his optimism about the partnership, stating that “NEAR boasts some of the most innovative solutions in the Web3 space. We anticipate that our partnership with NEAR will contribute to a significant 30% growth in our revenue.”

With such dedication to growth and innovation, the collaboration between NEAR Foundation and Seracle is shaping up to be an inspiring chapter in the evolution of the Web3 ecosystem. Leveraging cost-efficient technology, fostering a vibrant community, and providing robust financial support, this partnership stands as a beacon for the future of Web3 development.
---
id: maintenance-windows
title: Maintenance Windows
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

The RPC API enables you to query future maintenance windows for a specific validator in current epoch

---

## Maintenance windows {#maintenance-windows}

> The maintenance windows for a specific validator are future block height ranges in current epoch, in which the validator does not need produce block or chunk
> If the provided account is not a validator, then it will return the range from now to the end of the epoch.


- method: `EXPERIMENTAL_maintenance_windows`
- params:
  - `account_id`


example:


<Tabs>
<TabItem value="json" label="JSON" default>

```json
{
  "jsonrpc": "2.0",
  "id": "dontcare",
  "method": "EXPERIMENTAL_maintenance_windows",
  "params": {
    "account_id": "node0"
  }
}
```

</TabItem>
<TabItem value="http" label="HTTPie">

```bash
http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=EXPERIMENTAL_maintenance_windows \
  params:='{
    "account_id": "node0"
  }'
```

</TabItem>
</Tabs>

<details>
<summary>Example response:</summary>
<p>
The result will be a list of future maintenance windows in current epoch.
For example a window `[1028, 1031]` includes 1028, 1029 and 1030.

```json
{
    "jsonrpc": "2.0",
    "result": [
        [
            1028,
            1031
        ],
        [
            1034,
            1038
        ],
    ],
    "id": "dontcare"
}
```

</p>
</details>

#### What Could Go Wrong?? {#what-could-go-wrong}

When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow [verror](https://github.com/joyent/node-verror) convention for structuring the error response:


```json
{
    "error": {
        "name": <ERROR_TYPE>,
        "cause": {
            "info": {..},
            "name": <ERROR_CAUSE>
        },
        "code": -32000,
        "data": String,
        "message": "Server error",
    },
    "id": "dontcare",
    "jsonrpc": "2.0"
}
```

Here is the exhaustive list of the error variants that can be returned by `maintenance_windows` method:

<table className="custom-stripe">
  <thead>
    <tr>
      <th>
        ERROR_TYPE<br />
        <code>error.name</code>
      </th>
      <th>ERROR_CAUSE<br /><code>error.cause.name</code></th>
      <th>Reason</th>
      <th>Solution</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>INTERNAL_ERROR</td>
      <td>INTERNAL_ERROR</td>
      <td>Something went wrong with the node itself or overloaded</td>
      <td>
        <ul>
          <li>Try again later</li>
          <li>Send a request to a different node</li>
          <li>Check <code>error.cause.info</code> for more details</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>
Case Study: Aurora’s Alex Shevchenko on Scaling Solidity Smart Contracts
COMMUNITY
August 16, 2023
NEAR is a home to a number of amazing apps and projects. These developers, founders, and entrepreneurs are using NEAR to effortlessly create and distribute innovative decentralized apps, while helping build a more open web — free from centralized platforms. In these Case Study videos, NEAR Foundation showcases some of these projects. 

In the latest NEAR Foundation Case Study video below, Alex Shevchenko, co-founder and CEO of Aurora Labs, talks about the developer studio’s work in making it easier for developers integrating Solidity smart contracts on NEAR. 

“Aurora is a solution that allows you to launch your Solidity smart contracts on NEAR,” says Shevchenko. “We’re also adding something new: a scalability feature for the NEAR Protocol — something that can make EVM future-safe and make a destination of Aurora plus NEAR a final one for businesses to come.”

“We are focusing on the user experience,” he adds. “We have a whole set of products that are helping blockchain businesses to make the user experience much more convenient.”