consider how to enable taproot-like contracts as data (related to 2026 functions proposal)

[mr-zwets]

With the 2026 functions proposal taproot-like constructions become possible where people have MAST constructions and have to provide the contract as unlocking argument because only the hash of a contract spending path would be stored in the MAST leaves

It's a feature which would likely touch both the compiler and SDK.

@mainnet-pat did some interesting work on a similar feature in the Nexscript fork of CashScript which is designed for the nexa blockchain

The concept was called "MAST Contract Paths" or MCPs for short: https://nexscript.org/docs/guides/mcp/

The design consists of allow 'sub contracts' to de defined in contracts like the following:

pragma nexscript ^0.7.0;

contract Test(int visible unused a, int visible b, int c) {

  contract A(int visible unused a, int visible unused b, int c) {
    function funcA(string x, int y) {
        require(c == 3);

        require(x == "A");
        require(y == 1);
    }

    function funcB(int z) {
      require(z == 0);
    }
  }

  contract B(int a, int b, int c) {
    function funcA(string x, int y) {
        require(a == 1);
        require(b == 2);
        require(c == 3);

        require(x == "B");
        require(y == 1);
    }
  }
}

In the SDK usage of subcontracts in a MAST like construction looks like this:

import {
  ElectrumNetworkProvider,
  McpContract,
} from '@nexscript/nexscript';

const provider = new ElectrumNetworkProvider();
const mcp = new McpContract(mcpArtifact, [1n, 2n, 3n], { provider });

// send some satoshis to contract address in order to "deploy" it on chain
// await fund(mcp.address, 10000);

await mcp.execute({
  contractName: 'A',
  functionName: 'funcA',
  parameters: ['A', 1n],
}).to(aliceAddress, 1000n).withoutChange().send();

so a contract object is provided here as unlocking argument to an execute unlocking call on a MAST-like contract